Re: snd-usb-audio in ALSA 0.9.0rc5

Re: snd-usb-audio in ALSA 0.9.0rc5

[Clemens Ladisch]

Pedro Lopez-Cabanillas wrote:
> On Tuesday 12 November 2002 10:36, you wrote:
> > When you open the device as /dev/midiX (or /dev/snd/midiCXD0), ALSA will
> > open the first available subdevice, so you can access both ports by
> > opening /dev/midiX twice.
>
> This trick does work for input only, but not for output. Seems that /dev/midiX
> can be opened for output several times at once, but it mixes every MIDI
> events on the first MIDI port only. Anyway, it's funny but not a very
> practical solution, is it?

Sharing of output ports is an option with ALSA ports (/dev/snd/midiCxDy),
but it's always done with OSS ports (/dev/midix), probably for
compatibility reasons.

So, use /dev/snd/midiCcDd instead of /dev/midix.
Or delete /dev/midix and make it a symlink to /dev/snd/midiCcDd.  :-)

> > You can change the device number of /dev/amidiX with the "amidi_map"
> > parameter of the snd-rawmidi module. The default is
> >     options snd-rawmidi midi_map=0,0,0,0,0,0,0,0 amidi_map=1,1,1,1,1,1,1,1
> > meaning that /dev/midiX is device 0 and /dev/amidiX is device 1 for all
> > eight cards. If you change the amidi_map number for the 2x2 card to 0,
> > both /dev/midiX and /dev/amidiX will map to a port of the 2x2.
>
> That is also interesting, but a 'subdevice_map' option may be still more
> useful.

Yes, but we'd need two (for /dev/midiX and /dev/amidiX).
And it wouldn't help if you wanted to use more than two ports on a card.

> IMHO, mapping the card MIDI ports to subdevices may be OK, but only for ALSA
> native rawmidi. After all, you can access some MIDI port with "hw:x,y,z"
> instead of "hw:x,y", but for OSS emulation a better approach is needed. For
> major 14, why not to bind minors sequentially for each MIDI port on the
> system? I mean: first port minor=2, second port minor=18, ... thru -and up-
> minor=242 (/dev/midi15) if needed, regardless of ALSA card numbers?

This would break if cards are loaded dynamically, i.e. the port number
would depend on the order the drivers are loaded.

But the OSS emulation uses only 16 minors per card, and ALSA doesn't
handle more than 8 cards, so the minors 128..255 are currently unused.

Well, for obvous reasons (i.e. laziness), the current answer for this is
"don't use OSS".  ;-)


HTH
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html

Re: snd-usb-audio in ALSA 0.9.0rc5

[Pedro Lopez-Cabanillas]

On Wednesday 13 November 2002 09:50, Clemens Ladisch wrote:
> Pedro Lopez-Cabanillas wrote:
> > IMHO, mapping the card MIDI ports to subdevices may be OK, but only for
> > ALSA native rawmidi. After all, you can access some MIDI port with
> > "hw:x,y,z" instead of "hw:x,y", but for OSS emulation a better approach
> > is needed. For major 14, why not to bind minors sequentially for each
> > MIDI port on the system? I mean: first port minor=2, second port
> > minor=18, ... thru -and up- minor=242 (/dev/midi15) if needed, regardless
> > of ALSA card numbers?
>
> This would break if cards are loaded dynamically, i.e. the port number
> would depend on the order the drivers are loaded.

Yes, but not only the driver's loading order matters. With USB devices, the 
hub's port number and the plug-in order may cause troubles, too. With my UM-2 
and Midisport2x2, both using snd-usb-audio driver, i was used to cat 
/proc/asound/seq/clients from time to time, to know which client number had 
each device, until i've found a solution that is the same as for driver 
loading order. This is a snippet from my modules.conf file:

alias char-major-14 soundcore
alias char-major-116 snd
alias snd-card-0 snd-ens1371
alias snd-card-1 snd-usb-audio
alias snd-card-2 snd-usb-audio
options snd cards_limit=3
options snd-ens1371 index=0
options snd-usb-audio index=1,2 vid=0x0763,0x0582 pid=0x1110,0x0005

Since i've found this trick, i don't need to wonder about client numbers as 
they always are the same. It doesn' matter which device i plug-in first, 
neither which USB hub port it uses. 72 is always Midisport and 80 is UM-2.

I don't know if there is a better way, and i'm not sure if it shall work  for 
OSS rawmidi also. 

> Well, for obvous reasons (i.e. laziness), the current answer for this is
> "don't use OSS".  ;-)

You're kidding :-) You made a great, tireless work with ALSA usb driver, and 
ALSA as a whole is going to be beautiful too... but there are a lot of worthy   
OSS legacy apps (i.e. PD), and many cheap and ubiquitous USB MIDI multiport 
devices now. IMHO, ALSA should be able to give support to both worlds.

Of course, this issue must be addressed very carefully, having some previous 
discussions with final consensus.

About device minor numbers, i've heard that Linux 2.6 shall break actual  
limitations, with a 32 bits kdev_t, divided up to 12 bits for major and 20 
bits for minor. Anybody can confirm this?

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com



-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html

Re: snd-usb-audio in ALSA 0.9.0rc5

[Jaroslav Kysela]

On Thu, 14 Nov 2002, Pedro Lopez-Cabanillas wrote:

> On Wednesday 13 November 2002 09:50, Clemens Ladisch wrote:
> > Pedro Lopez-Cabanillas wrote:
> > > IMHO, mapping the card MIDI ports to subdevices may be OK, but only for
> > > ALSA native rawmidi. After all, you can access some MIDI port with
> > > "hw:x,y,z" instead of "hw:x,y", but for OSS emulation a better approach
> > > is needed. For major 14, why not to bind minors sequentially for each
> > > MIDI port on the system? I mean: first port minor=2, second port
> > > minor=18, ... thru -and up- minor=242 (/dev/midi15) if needed, regardless
> > > of ALSA card numbers?
> >
> > This would break if cards are loaded dynamically, i.e. the port number
> > would depend on the order the drivers are loaded.
> 
> Yes, but not only the driver's loading order matters. With USB devices, the 
> hub's port number and the plug-in order may cause troubles, too. With my UM-2 
> and Midisport2x2, both using snd-usb-audio driver, i was used to cat 
> /proc/asound/seq/clients from time to time, to know which client number had 
> each device, until i've found a solution that is the same as for driver 
> loading order. This is a snippet from my modules.conf file:
> 
> alias char-major-14 soundcore
> alias char-major-116 snd
> alias snd-card-0 snd-ens1371
> alias snd-card-1 snd-usb-audio
> alias snd-card-2 snd-usb-audio
> options snd cards_limit=3
> options snd-ens1371 index=0
> options snd-usb-audio index=1,2 vid=0x0763,0x0582 pid=0x1110,0x0005
> 
> Since i've found this trick, i don't need to wonder about client numbers as 
> they always are the same. It doesn' matter which device i plug-in first, 
> neither which USB hub port it uses. 72 is always Midisport and 80 is UM-2.
> 
> I don't know if there is a better way, and i'm not sure if it shall work  for 
> OSS rawmidi also. 
> 
> > Well, for obvous reasons (i.e. laziness), the current answer for this is
> > "don't use OSS".  ;-)
> 
> You're kidding :-) You made a great, tireless work with ALSA usb driver, and 
> ALSA as a whole is going to be beautiful too... but there are a lot of worthy   
> OSS legacy apps (i.e. PD), and many cheap and ubiquitous USB MIDI multiport 
> devices now. IMHO, ALSA should be able to give support to both worlds.
> 
> Of course, this issue must be addressed very carefully, having some previous 
> discussions with final consensus.
> 
> About device minor numbers, i've heard that Linux 2.6 shall break actual  
> limitations, with a 32 bits kdev_t, divided up to 12 bits for major and 20 
> bits for minor. Anybody can confirm this?

It's not implemented in 2.5:

typedef struct {
        unsigned short value;
} kdev_t;

#define KDEV_MINOR_BITS         8
#define KDEV_MAJOR_BITS         8


Have you tried to create the virtual MIDI device (snd-virmidi.o) ? You can
connect any sequencer port to a rawmidi device (and first two rawmidi
devices are mapped to the OSS space as well). Note that virmidi module can
occupy up to 8 card slots (in your environment with 3 real soundcards, you
can create up to 10 oss rawmidi devices).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: snd-usb-audio in ALSA 0.9.0rc5

[Clemens Ladisch]

Pedro Lopez-Cabanillas wrote:
> alias snd-card-1 snd-usb-audio
> alias snd-card-2 snd-usb-audio
> options snd-usb-audio index=1,2 vid=0x0763,0x0582 pid=0x1110,0x0005
>
> I don't know if there is a better way,

I created the vid/pid parameters for exactly this case.

> and i'm not sure if it shall work for OSS rawmidi also.

ALSA and OSS card numbers are the same for all devices, and the index
parameter works with all drivers (with snd-virmidi too).


HTH
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: snd-usb-audio in ALSA 0.9.0rc5

[Pedro Lopez-Cabanillas]

On Thursday 14 November 2002 10:09, Jaroslav Kysela wrote:
> Have you tried to create the virtual MIDI device (snd-virmidi.o) ? You can
> connect any sequencer port to a rawmidi device (and first two rawmidi
> devices are mapped to the OSS space as well). Note that virmidi module can
> occupy up to 8 card slots (in your environment with 3 real soundcards, you
> can create up to 10 oss rawmidi devices).

Thanks! this works! I didn't gave virmidi a shot before, but i think it is a 
good solution: i can use both ports of my USB devices with OSS programs.

BTW, there is a little problem with this module:

# modinfo snd-virmidi
filename:    /lib/modules/2.4.19/kernel/sound/drivers/snd-virmidi.o
description: "Dummy soundcard for virtual rawmidi devices"
author:      "Takashi Iwai <tiwai@suse.de>"
parm:        index int array (min = 1, max = 8), description "Index value for 
virmidi soundcard."
parm:        id string array (min = 1, max = 8), description "ID string for 
virmidi soundcard."
parm:        enable int array (min = 1, max = 8), description "Enable this 
soundcard."
parm:        midi_devs_Rb3ae63d0 int array (min = 1, max = 8), description 
"MIDI devices # (1-8)"

"midi_devs" is a versioned symbol belonging to OSS Free 
(linux/drivers/sound/dev_table.h) and i compiled my kernel with versioned 
symbols and OSS/free drivers.
Some releases ago this param was named "snd_midi_devs". Can we rename it 
again? Are there more clashes?

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html

Re: snd-usb-audio in ALSA 0.9.0rc5

[Jaroslav Kysela]

On Thu, 14 Nov 2002, Pedro Lopez-Cabanillas wrote:

> On Thursday 14 November 2002 10:09, Jaroslav Kysela wrote:
> > Have you tried to create the virtual MIDI device (snd-virmidi.o) ? You can
> > connect any sequencer port to a rawmidi device (and first two rawmidi
> > devices are mapped to the OSS space as well). Note that virmidi module can
> > occupy up to 8 card slots (in your environment with 3 real soundcards, you
> > can create up to 10 oss rawmidi devices).
> 
> Thanks! this works! I didn't gave virmidi a shot before, but i think it is a 
> good solution: i can use both ports of my USB devices with OSS programs.
> 
> BTW, there is a little problem with this module:
> 
> # modinfo snd-virmidi
> filename:    /lib/modules/2.4.19/kernel/sound/drivers/snd-virmidi.o
> description: "Dummy soundcard for virtual rawmidi devices"
> author:      "Takashi Iwai <tiwai@suse.de>"
> parm:        index int array (min = 1, max = 8), description "Index value for 
> virmidi soundcard."
> parm:        id string array (min = 1, max = 8), description "ID string for 
> virmidi soundcard."
> parm:        enable int array (min = 1, max = 8), description "Enable this 
> soundcard."
> parm:        midi_devs_Rb3ae63d0 int array (min = 1, max = 8), description 
> "MIDI devices # (1-8)"
> 
> "midi_devs" is a versioned symbol belonging to OSS Free 
> (linux/drivers/sound/dev_table.h) and i compiled my kernel with versioned 
> symbols and OSS/free drivers.
> Some releases ago this param was named "snd_midi_devs". Can we rename it 
> again? Are there more clashes?

I think that '#undef midi_devs' should be sufficient. Added to CVS.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html