bugs in usb midi alsa code?

bugs in usb midi alsa code?

[Fernando Pablo Lopez-Lezcano]

The MIDI interface I'm using is a Midisport 2x2 (same results with a 1x1).

It works fine with alsa cvs of 2002-08-20, has problems with alsa cvs of
2002-10-28.

This is a summary of what I have found so far. 

OSS emulation (raw midi interface):
  OSS programs using the raw midi interface emulation (I'm using pd) can't 
  see both midi ports in the oss emulation world. They only see the first
  port. This is confirmed by this:

  cat /proc/asound/oss/devices
   18: [1- 2]: raw midi

  Midi input and output works fine on the first port, byte counts can be 
  read through cat /proc/asound/card1/midi0.

  On the older alsa version the two interfaces show up:
  cat /proc/asound/oss/devices
   34: [2- 2]: raw midi
   45: [2-13]: raw midi

ALSA:
  input does not seem to work at all. I'm using the Muse MIDI sequencer, 
  with  the older alsa version it works fine (input), with the newer alsa 
  version it does not record midi input at all. Output works fine on both 
  alsa versions. 

  The input byte counters in /proc/asound/card1/midi0 do not increment. 

  cat /proc/asound/devices shows only one raw midi interface. This is on 
  a two port device (but Muse lets me select either port). On the older 
  alsa two devices show up on the listing. 

Has someone out there tested a similar configuration?
-- Fernando



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Fernando Pablo Lopez-Lezcano wrote:
> The MIDI interface I'm using is a Midisport 2x2 (same results with a 1x1).
>
> It works fine with alsa cvs of 2002-08-20, has problems with alsa cvs of
> 2002-10-28.

The driver has been changed to use rawmidi ports.

> ALSA:
>   cat /proc/asound/devices shows only one raw midi interface. This is on
>   a two port device (but Muse lets me select either port). On the older
>   alsa two devices show up on the listing.

For multiport interfaces, the additional ports are available as subdevices
of the rawmidi device, i.e. hw:1,0,0 and hw:1,0,1. (This is the same
behaviour as with other multiport interfaces, i.e. snd-mtpav and
snd-serial-u16550.)

>   input does not seem to work at all. I'm using the Muse MIDI sequencer,
>   with  the older alsa version it works fine (input), with the newer alsa
>   version it does not record midi input at all. Output works fine on both
>   alsa versions.

It worked when I tested it with midiloop and seq. Try using a sequencer
port instead of a rawmidi port.

>   The input byte counters in /proc/asound/card1/midi0 do not increment.

These counters increment only when somebody is reading from the port.
Try looking at them while executing "cat /dev/snd/midiCxD0".

> OSS emulation (raw midi interface):
>   OSS programs using the raw midi interface emulation (I'm using pd) can't
>   see both midi ports in the oss emulation world. They only see the first
>   port.

The OSS emulation doesn't support specifying a subdevice number.

If a rawmidi device is opened without a subdevice number, ALSA opens the
first available subdevice, so it would be possible to access both ports by
opening /dev/midix twice.
(It should be possible to map both /dev/midix and /dev/amidix to the same
device with the midi_map and amidi_map options of the snd-rawmidi module.)


HTH
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code

[Fernando Pablo Lopez-Lezcano]

> > ALSA:
> >   cat /proc/asound/devices shows only one raw midi interface. This is on
> >   a two port device (but Muse lets me select either port). On the older
> >   alsa two devices show up on the listing.
> 
> For multiport interfaces, the additional ports are available as subdevices
> of the rawmidi device, i.e. hw:1,0,0 and hw:1,0,1. (This is the same
> behaviour as with other multiport interfaces, i.e. snd-mtpav and
> snd-serial-u16550.)

I understand the backwards compatibility bit, but it still looks wrong to
me. AFAIK (maybe there are other uses) subdevices are only used in
soundcard pcm outputs when the underlying hardware is capable of multiple
opens on the same output port (hardware mixing). So the behavior of midi
ports in inconsistent with the behavior of audio ports. They are two
completely independent hardware i/o ports, it looks to me like they should
be two devices, not one.

> >   input does not seem to work at all. I'm using the Muse MIDI sequencer,
> >   with  the older alsa version it works fine (input), with the newer alsa
> >   version it does not record midi input at all. Output works fine on both
> >   alsa versions.
> 
> It worked when I tested it with midiloop and seq. Try using a sequencer
> port instead of a rawmidi port.

It looks like it is actually not working (from the other reports posted to 
the list). I'll try to do more tests latter. 

> > OSS emulation (raw midi interface):
> >   OSS programs using the raw midi interface emulation (I'm using pd) can't
> >   see both midi ports in the oss emulation world. They only see the first
> >   port.
> 
> The OSS emulation doesn't support specifying a subdevice number.
> 
> If a rawmidi device is opened without a subdevice number, ALSA opens the
> first available subdevice, so it would be possible to access both ports by
> opening /dev/midix twice.

IMHO this should be fixed, this as a bug as it makes a port unavailable to
existing oss applications. Either the oss emulation code (or whatever is
selecting and mapping oss devices to alsa devices) has to be fixed so that
it understands the midi subdevices quirk, and maps the oss devices
accordingly, or the subdevices for multiple midi ports have to be
transformed into devices so that the current oss code can recognize them.

The last fix makes most sense from my viewpoint and would make behavior of
pcm and midi consistent.

-- Fernando



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

usb audio sound quality

[Patrick Shirkey]

I have done extensive testing now and can say that the jack quality is 
exactly the same as the quality from accessing alsa directly with the 
quattro.

Before the merge of the modules jack would not work at all but the sound 
quality of the quattro was crisp and clean. Now jack has absolutely no 
problems but the quality is inferior.

The sound is distorted for any notes that go over a certain volume 
threshhold. It's like the more full the sound is the more likely it will 
distort. I have tested with the output level buttons in and out. The 
sound quality is much improved but still noticibly distorted when the 
button is in.

This is from the manual:

1/2 "Output Level" switch: In the `out' position, the Quattro Outputs 1 
& 2 are set to +4dBu line level operation. Pressing in and engaging this 
switch sets these outputs to -10dBV line level.




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: usb audio sound quality

[Patrick Shirkey]

I'm getting a lot of wierd sound quality bugs while using JACK. It seems 
like the driver is storing the crappyness somewhere and each time I 
access it the quality gets worse. Is it possible that the driver could 
allow the data to linger and make things unstable?

I have been doing some testing today with various softsynths and my mem 
is getting pretty full. Turning off jack just freed up 10MB but still 
it's at

Mem:    386484K total,   336212K used,    50272K free,    41304K buffers

The machine has been up for 7 hours. Is that reasonable?


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: usb audio sound quality

[Patrick Shirkey]

Patrick Shirkey wrote:
> I'm getting a lot of wierd sound quality bugs while using JACK. It seems 
> like the driver is storing the crappyness somewhere and each time I 
> access it the quality gets worse. Is it possible that the driver could 
> allow the data to linger and make things unstable?
> 
> I have been doing some testing today with various softsynths and my mem 
> is getting pretty full. Turning off jack just freed up 10MB but still 
> it's at
> 
> Mem:    386484K total,   336212K used,    50272K free,    41304K buffers
> 
> The machine has been up for 7 hours. Is that reasonable?
> 

I have just tested a cool machine with native alsa and the quality is 
crystal clear. Testing with JACK caused and through alsa while running 
JACK caused the degradation again. I will work on the assumption that 
means that the stress of running JACK is the culprit of audio quality 
degradation and I guess that ssm (and possibly JACK) has some mem leaks. 
Thanks for your work Takashi and Clemens.




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: usb audio sound quality

[Patrick Shirkey]

Patrick Shirkey wrote:
> 
> I guess that ssm (and possibly JACK) has some mem leaks. 
> 

It seems I spoke too soon. I'm seeing memory leaks while using 
alsaplayer or xmms. Alsaplayer connected via the alsa driver and xmms 
through oss.

I'm going through about 1 MB/min :(

Is this an alsa issue or should I be looking on the usb lists, going for 
a new kernel...?



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

snd-usb-midi vs ohci

[Patrick Shirkey]

I'm have a machine which needs the ohci usb driver. I have 2.4.19-pre10 
kernel for it.

When I try to load the usb-audio module I get a constant stream of

snd-usb-midi: usb_submit_urb: -22

Which doesn't stop until I remove the module.

This happens if I compile alsa-driver with or without sequencer support.


-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd-usb-midi vs ohci

[Clemens Ladisch]

Patrick Shirkey wrote:
> I'm have a machine which needs the ohci usb driver. I have 2.4.19-pre10
> kernel for it.
>
> When I try to load the usb-audio module I get a constant stream of
>
> snd-usb-midi: usb_submit_urb: -22
>
> Which doesn't stop until I remove the module.

In the 2.5.45 kernel, the behaviour of interrupt transfers (used for
Roland and Quattro MIDI input) changed, so snd-usb-midi was changed as
well, but this change was incompatible with earlier kernels.
It's now fixed on CVS.

BTW: please test the MIDI input with "alsa-lib/tests/rawmidi -v -i hw:x,0",
it would be nice to know if the M-Audio protocol support works at all.
I guess the Quattro is sending a stream of Active Sensing bytes (0xfe).


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: bugs in usb midi alsa code

[Fernando Pablo Lopez-Lezcano]

> > > ALSA:
> > >   cat /proc/asound/devices shows only one raw midi interface. This is on
> > >   a two port device (but Muse lets me select either port). On the older
> > >   alsa two devices show up on the listing.
> > 
> > For multiport interfaces, the additional ports are available as subdevices
> > of the rawmidi device, i.e. hw:1,0,0 and hw:1,0,1. (This is the same
> > behaviour as with other multiport interfaces, i.e. snd-mtpav and
> > snd-serial-u16550.)
> 
> I understand the backwards compatibility bit, but it still looks wrong to
> me. [MUNCH]

But let me add (I should have said this explicitly before) that the
overall usb midi driver support is now MUCH better than before. Great
piece of work. Just missing (IMHO) a few details. 

-- Fernando



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code

[Paul Davis]

>> > ALSA:
>> >   cat /proc/asound/devices shows only one raw midi interface. This is on
>> >   a two port device (but Muse lets me select either port). On the older
>> >   alsa two devices show up on the listing.
>> 
>> For multiport interfaces, the additional ports are available as subdevices
>> of the rawmidi device, i.e. hw:1,0,0 and hw:1,0,1. (This is the same
>> behaviour as with other multiport interfaces, i.e. snd-mtpav and
>> snd-serial-u16550.)
>
>I understand the backwards compatibility bit, but it still looks wrong to
>me. AFAIK (maybe there are other uses) subdevices are only used in
>soundcard pcm outputs when the underlying hardware is capable of multiple
>opens on the same output port (hardware mixing). So the behavior of midi
>ports in inconsistent with the behavior of audio ports. They are two
>completely independent hardware i/o ports, it looks to me like they should
>be two devices, not one.

i'm with fernando on this one. if consistency is the goal, and i think
it should be, then multiport MIDI devices should appear as multiple
ports, not subdevices. 

--p


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code

[Jaroslav Kysela]

On Wed, 6 Nov 2002, Paul Davis wrote:

> >> > ALSA:
> >> >   cat /proc/asound/devices shows only one raw midi interface. This is on
> >> >   a two port device (but Muse lets me select either port). On the older
> >> >   alsa two devices show up on the listing.
> >> 
> >> For multiport interfaces, the additional ports are available as subdevices
> >> of the rawmidi device, i.e. hw:1,0,0 and hw:1,0,1. (This is the same
> >> behaviour as with other multiport interfaces, i.e. snd-mtpav and
> >> snd-serial-u16550.)
> >
> >I understand the backwards compatibility bit, but it still looks wrong to
> >me. AFAIK (maybe there are other uses) subdevices are only used in
> >soundcard pcm outputs when the underlying hardware is capable of multiple
> >opens on the same output port (hardware mixing). So the behavior of midi
> >ports in inconsistent with the behavior of audio ports. They are two
> >completely independent hardware i/o ports, it looks to me like they should
> >be two devices, not one.
> 
> i'm with fernando on this one. if consistency is the goal, and i think
> it should be, then multiport MIDI devices should appear as multiple
> ports, not subdevices. 

We have no minor numbers for direct addressing of tenths rawmidi devices.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code

[Fernando Pablo Lopez-Lezcano]

> > >> > ALSA:
> > >> >   cat /proc/asound/devices shows only one raw midi interface. This is on
> > >> >   a two port device (but Muse lets me select either port). On the older
> > >> >   alsa two devices show up on the listing.
> > >> 
> > >> For multiport interfaces, the additional ports are available as subdevices
> > >> of the rawmidi device, i.e. hw:1,0,0 and hw:1,0,1. (This is the same
> > >> behaviour as with other multiport interfaces, i.e. snd-mtpav and
> > >> snd-serial-u16550.)
> > >
> > >I understand the backwards compatibility bit, but it still looks wrong to
> > >me. AFAIK (maybe there are other uses) subdevices are only used in
> > >soundcard pcm outputs when the underlying hardware is capable of multiple
> > >opens on the same output port (hardware mixing). So the behavior of midi
> > >ports in inconsistent with the behavior of audio ports. 
> > 
> > i'm with fernando on this one. if consistency is the goal, and i think
> > it should be, then multiport MIDI devices should appear as multiple
> > ports, not subdevices. 
> 
> We have no minor numbers for direct addressing of tenths rawmidi devices.

That's really too bad. What does that address space look like at this
point and how is it used? (ie: what is it that is available?) Sorry for
the ignorance. Or is this related to allocation of new device numbers?  
(I seem to remember that at some point Linus, I think, sort of forbid to
add new ones).

Is it possible to at least to fix the behavior in the OSS world?  As it is
now, the only visible interface is the first one. 

-- Fernando



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code

[Clemens Ladisch]

Fernando Pablo Lopez-Lezcano wrote:
> > > i'm with fernando on this one. if consistency is the goal, and i think
> > > it should be, then multiport MIDI devices should appear as multiple
> > > ports, not subdevices.

BTW: The old driver had one (emulated) rawmidi device per sequencer port,
each having 16(?) subdevices to enable concurrent access.

> > We have no minor numbers for direct addressing of tenths rawmidi devices.

We have eight minor numbers. On 8-port interfaces like the UM-880 or the
MidiSport 8x8, the ninth port (for control/timing data) is the most
interesting one.

> That's really too bad. What does that address space look like at this
> point and how is it used? (ie: what is it that is available?)

There is one major number each for OSS (14) and ALSA (116), so we have 256
minor numbers for all devices.

ALSA supports up to 8 cards, so there are 32 minors per card.
There are 8 rawmidi minors (8-15).

OSS has 16 minors per card.
Rawmidi devices use 2 (/dev/midix) and 13 (/dev/amidix).

The other minors are mostly used for other devices (see minor.h), but at
least for OSS it may be possible to use the "reserved" numbers 7 and 15
for two other rawmidi devices. Hmmm, /dev/bmidix and /dev/cmidix? :-)

> Is it possible to at least to fix the behavior in the OSS world?

I think it would be possible to add two more options (midi_minor_map and
amidi_minor_map) to the snd-rawmidi module, but I'm not sure this would be
the best solution.


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

CS4205 SPDIF

[Matias Alejo Garcia]

Hi!

   I was able to use the SPDIF output of my Dell I8200 (CS4205 crappy
sound), by making the following small change in the alsa drivers:

===================================================================
RCS file: RCS/ac97_id.h,v
45c45,46
< #define AC97_ID_CS4205		0x43525958
---
> #define AC97_ID_CS4205		0x4352595B


Now, I have the IEC958 controls OK, and everything works, but, I still
wasn't able to output an AC3 stream into the SPDIF.

My card has no LFE, and REAR controls in the alsamixer. That is ok,
because the CS4205 is not a 5.1 sound card, at least in the 'analog'
sense.

If I try aplay -D plug:rear or aplay -D plug:lfe or aplay -D
plug:surround51 I get things like:
'aplay: set_params:764: Broken configuration for this PCM: no
configurations available'
which I think is ok. '-D plug:iec958' works.

BUT, what about sending a AC3 stream directly to the SPDIF?? How can I
do that??
I tried:
  ac3play --card 0,0 matrix.ac3
but I get nothing but noise. The same noise with
   mplayer -ao alsa9:iec958 -ac hwac3 -dvd 1

Mplayer tell me:
alsa-init: requested format: 48000 Hz, 2 channels, AC3
alsa-init: soundcard set to iec958:AES0=0x2,AES1=0x82,AES2=0x0,AES3=0x2

if I tried -channels 6, mplayer tried 'surround51' and I get other
error.

Any idea how can I try to do that??? Thank you very much!! 

Matias



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Werner Schweer]

On Tuesday 05 November 2002 21:22, Fernando Pablo Lopez-Lezcano wrote:
> The MIDI interface I'm using is a Midisport 2x2 (same results with a 1x1).
>
> It works fine with alsa cvs of 2002-08-20, has problems with alsa cvs of
> 2002-10-28.
>
> This is a summary of what I have found so far.
...
> ALSA:
>   input does not seem to work at all. I'm using the Muse MIDI sequencer,
>   with  the older alsa version it works fine (input), with the newer alsa
>   version it does not record midi input at all. Output works fine on both
>   alsa versions.

same on my Roland/Edirol UA100 (audio + 2 midi ports). Midi Input does
not work.

    - Werner






-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Wed, Nov 06, 2002 at 11:52:05AM +0100, Werner Schweer wrote:
> 
> On Tuesday 05 November 2002 21:22, Fernando Pablo Lopez-Lezcano wrote:
> > The MIDI interface I'm using is a Midisport 2x2 (same results with a 1x1).
> >
> > It works fine with alsa cvs of 2002-08-20, has problems with alsa cvs of
> > 2002-10-28.
> >
> > This is a summary of what I have found so far.
> ...
> > ALSA:
> >   input does not seem to work at all. I'm using the Muse MIDI sequencer,
> >   with  the older alsa version it works fine (input), with the newer alsa
> >   version it does not record midi input at all. Output works fine on both
> >   alsa versions.
> 
> same on my Roland/Edirol UA100 (audio + 2 midi ports). Midi Input does
> not work.
> 

last but not least: same on my Evolution MK-249C keyboard using OPL3 or
amSynth. midi input doesn't work with alsa cvs ATM. we have a bug!


martin



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Fernando Pablo Lopez-Lezcano wrote:
> OSS emulation (raw midi interface):
>   Midi input and output works fine on the first port,
> ALSA:
>   input does not seem to work at all.

Werner Schweer wrote:
> same on my Roland/Edirol UA100 (audio + 2 midi ports).

Martin Langer wrote:
> last but not least: same on my Evolution MK-249C keyboard

I don't think the bug is in the snd-usb-audio driver because OSS input
seems to be working.

Please try the following with the rawmidi program in alsa-lib/test:
OSS:         rawmidi -v -I /dev/midix
ALSA direct: rawmidi -v -I /dev/snd/midiCxD0
ALSA Lib:    rawmidi -v -i hw:x,0
ALSA Lib:    rawmidi -v -i hw:x,0,0

Did you update alsa-lib together with alsa-kernel? Are you sure you have
the correct version of libasound installed, and your programs are using
it?


HTH
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 09:10:33AM +0100, Clemens Ladisch wrote:
> 
> I don't think the bug is in the snd-usb-audio driver because OSS input
> seems to be working.
> 
> Please try the following with the rawmidi program in alsa-lib/test:
> OSS:         rawmidi -v -I /dev/midix
> ALSA direct: rawmidi -v -I /dev/snd/midiCxD0
> ALSA Lib:    rawmidi -v -i hw:x,0
> ALSA Lib:    rawmidi -v -i hw:x,0,0
> 

it starts correctly and hangs finally after the Output line: 

tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i hw:2,0
Using: 
Input: device hw:2,0
Output: NONE

> Did you update alsa-lib together with alsa-kernel? Are you sure you have
> the correct version of libasound installed, and your programs are using
> it?
> 

yes, I'm always doing a "make build" which is diving in each directory and
executing ./cvscompile. So I think everything is freshly build on my machine.
If not correct me please.

tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ldconfig -v|grep libasound
        libasound.so.2 -> libasound.so.2.0.0
	libasound.so.1 -> libasound.so.1.0.1

The program I was using is aconnect doing a simple connection between OPL3
and my keyboard. Aconnect was even freshly build and the opl3 works fine
playing midi files with pmidi.

Sorry, but I can't find another interesting information. The interfaces are
there. The only thing I miss is some data from midi input, but the hanging
rawmidi process is a good starting point.


martin


-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Martin Langer wrote:
> On Thu, Nov 07, 2002 at 09:10:33AM +0100, Clemens Ladisch wrote:
> > Please try the following with the rawmidi program in alsa-lib/test:
> > OSS:         rawmidi -v -I /dev/midix
> > ALSA direct: rawmidi -v -I /dev/snd/midiCxD0
> > ALSA Lib:    rawmidi -v -i hw:x,0
> > ALSA Lib:    rawmidi -v -i hw:x,0,0
>
> it starts correctly and hangs finally after the Output line:
>
> tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i hw:2,0
> Using:
> Input: device hw:2,0
> Output: NONE

rawmidi only checks for Ctrl+C after some data has been output.

Does it work with /dev/midi2 and /dev/snd/midiC2D0?


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 11:09:51AM +0100, Clemens Ladisch wrote:
> Martin Langer wrote:
> > On Thu, Nov 07, 2002 at 09:10:33AM +0100, Clemens Ladisch wrote:
> > > Please try the following with the rawmidi program in alsa-lib/test:
> > > OSS:         rawmidi -v -I /dev/midix
> > > ALSA direct: rawmidi -v -I /dev/snd/midiCxD0
> > > ALSA Lib:    rawmidi -v -i hw:x,0
> > > ALSA Lib:    rawmidi -v -i hw:x,0,0
> >
> > it starts correctly and hangs finally after the Output line:
> >
> > tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i hw:2,0
> > Using:
> > Input: device hw:2,0
> > Output: NONE
> 
> rawmidi only checks for Ctrl+C after some data has been output.
> 
> Does it work with /dev/midi2 and /dev/snd/midiC2D0?
> 

not really. 

martin



tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i /dev/midi2
Using: 
Input: device /dev/midi2
Output: NONE
ALSA lib rawmidi.c:278:(snd_rawmidi_open_noupdate) Unknown RawMidi /dev/midi2
snd_rawmidi_open /dev/midi2 failed: -2
Closing

tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i
/dev/snd/midiC2D0  
Using: 
Input: device /dev/snd/midiC2D0
Output: NONE
ALSA lib rawmidi.c:278:(snd_rawmidi_open_noupdate) Unknown RawMidi
/dev/snd/midiC2D0
snd_rawmidi_open /dev/snd/midiC2D0 failed: -2
Closing



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 11:21:36AM +0100, Martin Langer wrote:
> 
> 
> tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i /dev/midi2
> Using: 
> Input: device /dev/midi2
> Output: NONE
> ALSA lib rawmidi.c:278:(snd_rawmidi_open_noupdate) Unknown RawMidi /dev/midi2
> snd_rawmidi_open /dev/midi2 failed: -2
> Closing
> 
> tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i
> /dev/snd/midiC2D0  
> Using: 
> Input: device /dev/snd/midiC2D0
> Output: NONE
> ALSA lib rawmidi.c:278:(snd_rawmidi_open_noupdate) Unknown RawMidi
> /dev/snd/midiC2D0
> snd_rawmidi_open /dev/snd/midiC2D0 failed: -2
> Closing
> 

I should use big I's!

martin



tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -I /dev/snd/midiC2D0 
Using: 
Input: /dev/snd/midiC2D0
Output: NONE
Read midi in
Press ctrl-c to stop
read fe
read fe
read fe
read fe
read fe
read fe
read fe
...



tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -I /dev/snd/midi2    
Using: 
Input: /dev/snd/midi2
Output: NONE
open /dev/snd/midi2 for input failed
Closing



-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 11:34:02AM +0100, Martin Langer wrote:
> On Thu, Nov 07, 2002 at 11:21:36AM +0100, Martin Langer wrote:
> > 
> 
> 
> tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -I /dev/snd/midi2    
> Using: 
> Input: /dev/snd/midi2
> Output: NONE
> open /dev/snd/midi2 for input failed
> Closing
> 

This is definitely not my day! Now I've tried /dev/midi2 instead of
/dev/snd/midi2. It's running so far. /dev/snd/midi2 doesn't exist.

sorry,
martin



tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -I /dev/midi2
Using: 
Input: /dev/midi2
Output: NONE
Read midi in
Press ctrl-c to stop
read fe
read fe
...


-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Martin Langer wrote:
> tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -I /dev/midi2
> Using:
> Input: /dev/midi2
> Output: NONE
> Read midi in
> Press ctrl-c to stop
> read fe
> read fe
> ...

> tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -I /dev/snd/midiC2D0
> Using:
> Input: /dev/snd/midiC2D0
> Output: NONE
> Read midi in
> Press ctrl-c to stop
> read fe
> read fe
> ...

So ALSA rawmidi works, too.

Apparently, the bug only occurs if a rawmidi port is used through the
alsa-lib functions. (The subdevice checking code in rawmidi_hw.c did
change, but that was a bugfix. Hmmm...)

And I'm still not able to reproduce it on my machine. I'll test with a
fresh checkout and the official rc5 tonight.

Did anybody test with a non-USB device?


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 01:50:29PM +0100, Clemens Ladisch wrote:
> 
> So ALSA rawmidi works, too.
> 
> Apparently, the bug only occurs if a rawmidi port is used through the
> alsa-lib functions. (The subdevice checking code in rawmidi_hw.c did
> change, but that was a bugfix. Hmmm...)

commenting out that new line doesn't help!

> 

In former days I have had these lines in /proc/asound/seq/clients. There
were two endpoints for each direction.
Client  64 : "Evolution Electronics Ltd. MK-249C USB MIDI keyboard" [Kernel]
  Port   0 : "MK-249C USB MIDI keyboard Port 0" (R-e-)
  Port   1 : "MK-249C USB MIDI keyboard Port 1" (-We-)


Now I have two endpoints in the messages, but a mixed entry in the clients
list. Is this correct or do we have a multi endpoint problem?

[...]
Nov  7 14:18:55 tuba kernel: snd-usb-midi: detected 1 input jack(s) on
endpoint 1
Nov  7 14:18:55 tuba kernel: snd-usb-midi: detected 1 output jack(s) on
endpoint 2
[...]


Today /proc/asound/seq/clients shows me only one port of my keyboard and the
description doesn't has the port number included like above.

tuba:~# cat /proc/asound/seq/clients 
[...]
Client  80 : "External MIDI 2" [Kernel]
  Port   0 : "MK-249C USB MIDI keyboard Port " (RWeX)
[...]


I hope this can help

martin


-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Martin Langer wrote:
> On Thu, Nov 07, 2002 at 01:50:29PM +0100, Clemens Ladisch wrote:
> > Apparently, the bug only occurs if a rawmidi port is used through the
> > alsa-lib functions. (The subdevice checking code in rawmidi_hw.c did
> > change, but that was a bugfix. Hmmm...)
>
> commenting out that new line doesn't help!

It fixed a bug. Without that line, opening a specific input-only rawmidi
subdevice with a subdevice number would fail.

> In former days I have had these lines in /proc/asound/seq/clients. There
> were two endpoints for each direction.
> Client  64 : "Evolution Electronics Ltd. MK-249C USB MIDI keyboard" [Kernel]
>   Port   0 : "MK-249C USB MIDI keyboard Port 0" (R-e-)
>   Port   1 : "MK-249C USB MIDI keyboard Port 1" (-We-)

Having seperate ports for each endpoint was a side effect of the endpoint
handling code. Using rawmidi had the side effect of fixing this. :-)

> Now I have two endpoints in the messages, but a mixed entry in the clients
> list. Is this correct or do we have a multi endpoint problem?

It's correct, and I consider it more correct than one port for each
direction, from a usability point of view.

> ... the description doesn't has the port number included like above.
>
> Client  80 : "External MIDI 2" [Kernel]
>   Port   0 : "MK-249C USB MIDI keyboard Port " (RWeX)

The sequencer allocates 64 bytes for port names, but rawmidi ports have
only 32 bytes (including the terminating zero). You should've bought an
MK-249 instead. ;-)


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 01:50:29PM +0100, Clemens Ladisch wrote:
> 
> 
> Did anybody test with a non-USB device?
> 

my keyboard has an additional classical MIDI OUT jack. Using this instead of
USB is running fine with OPL3 and amSynth. No problem occured.


martin


-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Martin Langer wrote:
> On Thu, Nov 07, 2002 at 01:50:29PM +0100, Clemens Ladisch wrote:
> > Did anybody test with a non-USB device?
>
> my keyboard has an additional classical MIDI OUT jack. Using this instead of
> USB is running fine with OPL3 and amSynth. No problem occured.

What device did you use to get the MIDI data into the computer?


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 05:35:48PM +0100, Clemens Ladisch wrote:
> Martin Langer wrote:
> > On Thu, Nov 07, 2002 at 01:50:29PM +0100, Clemens Ladisch wrote:
> > > Did anybody test with a non-USB device?
> >
> > my keyboard has an additional classical MIDI OUT jack. Using this instead of
> > USB is running fine with OPL3 and amSynth. No problem occured.
> 
> What device did you use to get the MIDI data into the computer?
> 

my onboard soundcard "snd-via82xx" with game/midi-port

tuba:/tmp# cat /proc/asound/cards 
0 [82C686AB       ]: VIA686A - VIA 82C686A/B
                     VIA 82C686A/B at 0xcc00, irq 7
[..]


tuba:/tmp# cat /proc/asound/card0/id 
82C686AB


tuba:/tmp# cat /proc/asound/card0/midi0 
MPU-401 (UART)

Output 0
  Tx bytes     : 0
  Input 0
  Rx bytes     : 54393
  Buffer size  : 4096
  Avail        : 0
  Overruns     : 0


martin

-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Fernando Pablo Lopez-Lezcano]

> > OSS emulation (raw midi interface):
> >   Midi input and output works fine on the first port,
> > ALSA:
> >   input does not seem to work at all.
> 
> Werner Schweer wrote:
> > same on my Roland/Edirol UA100 (audio + 2 midi ports).
> 
> Martin Langer wrote:
> > last but not least: same on my Evolution MK-249C keyboard
> 
> I don't think the bug is in the snd-usb-audio driver because OSS input
> seems to be working.

Yes, it is weird...

> Please try the following with the rawmidi program in alsa-lib/test:
> OSS:         rawmidi -v -I /dev/midix

  ./rawmidi -v -I /dev/midi1 --> works fine

> ALSA direct: rawmidi -v -I /dev/snd/midiCxD0

  ./rawmidi -v -I /dev/snd/midiC1D0 --> works fine

> ALSA Lib:    rawmidi -v -i hw:x,0

./rawmidi -v -i hw:1,0
Using: 
Input: device hw:1,0
Output: NONE
ALSA lib rawmidi.c:247:(snd_rawmidi_open_conf) symbol _snd_rawmidi_hw_open 
is not defined inside (null)
snd_rawmidi_open hw:1,0 failed: -6
Closing

> ALSA Lib:    rawmidi -v -i hw:x,0,0

Same as the previous test.

> Did you update alsa-lib together with alsa-kernel? Are you sure you have
> the correct version of libasound installed, and your programs are using
> it?

alsa-driver, alsa-kernel, alsa-lib and alsa-utils are compiled and 
installed from the same source tree (or so I think). 

-- Fernando



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Thu, Nov 07, 2002 at 10:54:10AM -0800, Fernando Pablo Lopez-Lezcano wrote:
> 
> ./rawmidi -v -i hw:1,0
> Using: 
> Input: device hw:1,0
> Output: NONE
> ALSA lib rawmidi.c:247:(snd_rawmidi_open_conf) symbol _snd_rawmidi_hw_open 
> is not defined inside (null)
> snd_rawmidi_open hw:1,0 failed: -6
> Closing
> 


I can't reproduce this, but I was playing a little bit with rawmidi...
So, if my client is aconnected (aconnect 80:0 73:0) I can't catch an error
with rawmidi trying all four possibilties.

If I disconnect (aconnect -x) my keyboard I can produce an error. This
situation is the only possibility to see an error message and it must be
"rawmidi -v -i hw:2,0,0". The other three rawmidi options are running fine and
didn't show an error. Yes, "rawmidi -v -i hw:2,0" does his job without
problems and the message is also different to Fernando's output.

tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i hw:2,0,0
Using: 
Input: device hw:2,0,0
Output: NONE
ALSA lib rawmidi_hw.c:247:(snd_rawmidi_hw_open) SNDRV_RAWMIDI_IOCTL_INFO
failed: No such device
snd_rawmidi_open hw:2,0,0 failed: -19
Closing


martin


-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Martin Langer wrote:
> So, if my client is aconnected (aconnect 80:0 73:0) I can't catch an error
> with rawmidi trying all four possibilties.

When the sequencer has opened the port, others cannot access it, so that's
OK.

BTW: Does input through the sequencer work?

> If I disconnect (aconnect -x) my keyboard I can produce an error. This
> situation is the only possibility to see an error message and it must be
> "rawmidi -v -i hw:2,0,0". The other three rawmidi options are running fine and
> didn't show an error.
>
> tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i hw:2,0,0
> Using:
> Input: device hw:2,0,0
> Output: NONE
> ALSA lib rawmidi_hw.c:247:(snd_rawmidi_hw_open) SNDRV_RAWMIDI_IOCTL_INFO failed: No such device
> snd_rawmidi_open hw:2,0,0 failed: -19
> Closing

This happens when you remove the bugfix I mentioned yesterday. Without the
fix, snd_rawmidi_hw_open always asks for the output stream information.
(If you do have that bugfix, you're using some older version of alsa-lib.)

> Yes, "rawmidi -v -i hw:2,0" does his job without
> problems and the message is also different to Fernando's output.

In theory, that means when you use current CVS as it is (with the bugfix),
everything should work on your machine?

I'm slightly confused now. It seems you (Martin/Fernando/Werner) have
different errors.


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Martin Langer]

On Fri, Nov 08, 2002 at 09:17:45AM +0100, Clemens Ladisch wrote:
> Martin Langer wrote:
> 
> BTW: Does input through the sequencer work?

yes it's working with the same keyboard using classical MIDI OUT jack, not
USB. I have done this:

tuba:~# aconnect 64:0 73:0    /* using classical midi jack works great */
tuba:~# aconnect -x
tuba:~# aconnect 80:0 73:0    /* using usb jack doesn't work: no sound */
tuba:~# aconnect -x
tuba:~# aconnect 64:0 73:0    /* using midi jack works great as before */


> >
> > tuba:/usr/local/src/alsa-cvs/alsa-lib/test# ./rawmidi -v -i hw:2,0,0
> > Using:
> > Input: device hw:2,0,0
> > Output: NONE
> > ALSA lib rawmidi_hw.c:247:(snd_rawmidi_hw_open) SNDRV_RAWMIDI_IOCTL_INFO failed: No such device
> > snd_rawmidi_open hw:2,0,0 failed: -19
> > Closing
> 
> This happens when you remove the bugfix I mentioned yesterday. Without the
> fix, snd_rawmidi_hw_open always asks for the output stream information.
> (If you do have that bugfix, you're using some older version of alsa-lib.)
> 

ooops, my fault. now "rawmidi -v -i hw:2,0,0" runs fine.

> > Yes, "rawmidi -v -i hw:2,0" does his job without
> > problems and the message is also different to Fernando's output.
> 
> In theory, that means when you use current CVS as it is (with the bugfix),
> everything should work on your machine?
> 

Now using cvs checkout from today and it's impossible to produce an error
message with rawmidi. so far it's ok.

With rawmidi I can influence my counter at /proc/asound/card2/midi0 but not
with keyboard playing (the bytes number is constant).

martin


-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

[PATCH] USB MIDI bugs

[Clemens Ladisch]

This fixes sequencer input from USB MIDI. Both usbmidi.c and seq_midi.c
thought they could use substream->runtime->private_data for themselves.

Additionally, interrupt transfer resubmissions for kernels before 2.5.45
are removed again.

-- 
Clemens



Index: alsa-driver/include/adriver.h
===================================================================
RCS file: /cvsroot/alsa/alsa-driver/include/adriver.h,v
retrieving revision 1.22
diff -u -r1.22 adriver.h
--- alsa-driver/include/adriver.h	1 Nov 2002 13:25:22 -0000	1.22
+++ alsa-driver/include/adriver.h	11 Nov 2002 08:02:40 -0000
@@ -258,6 +258,10 @@
 #define get_cfg_desc(cfg)	(cfg)
 #endif

+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 45)
+#define usb_pipe_needs_resubmit(pipe) (!usb_pipeint(pipe))
+#endif
+
 #endif /* SND_NEED_USB_WRAPPER && CONFIG_USB */

 #include "amagic.h"


Index: alsa-kernel/usb/usbaudio.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.h,v
retrieving revision 1.7
diff -u -r1.7 usbaudio.h
--- alsa-kernel/usb/usbaudio.h	1 Nov 2002 13:25:01 -0000	1.7
+++ alsa-kernel/usb/usbaudio.h	11 Nov 2002 08:03:33 -0000
@@ -202,4 +202,8 @@
 #define get_cfg_desc(cfg)	(&(cfg)->desc)
 #endif

+#ifndef usb_pipe_needs_resubmit
+#define usb_pipe_needs_resubmit(pipe) 1
+#endif
+
 #endif /* __USBAUDIO_H */
Index: alsa-kernel/usb/usbmidi.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbmidi.c,v
retrieving revision 1.9
diff -u -r1.9 usbmidi.c
--- alsa-kernel/usb/usbmidi.c	1 Nov 2002 13:25:01 -0000	1.9
+++ alsa-kernel/usb/usbmidi.c	11 Nov 2002 08:03:33 -0000
@@ -114,7 +114,6 @@
 	struct urb* urb;
 	struct usbmidi_in_port {
 		snd_rawmidi_substream_t* substream;
-		int active;
 	} ports[0x10];
 };

@@ -159,7 +158,12 @@
 	int cable = packet[0] >> 4;
 	usbmidi_in_port_t* port = &ep->ports[cable];

-	if (!port->active)
+	if (!port->substream) {
+		snd_printd("unexpected port %d!\n", cable);
+		return;
+	}
+	if (!port->substream->runtime ||
+	    !port->substream->runtime->trigger)
 		return;
 	snd_rawmidi_receive(port->substream, &packet[1],
 			    snd_usbmidi_cin_length[packet[0] & 0x0f]);
@@ -184,8 +188,10 @@
 			return;
 	}

-	urb->dev = ep->umidi->chip->dev;
-	snd_usbmidi_submit_urb(urb, GFP_ATOMIC);
+	if (usb_pipe_needs_resubmit(urb->pipe)) {
+		urb->dev = ep->umidi->chip->dev;
+		snd_usbmidi_submit_urb(urb, GFP_ATOMIC);
+	}
 }

 /*
@@ -451,20 +457,6 @@

 static int snd_usbmidi_input_open(snd_rawmidi_substream_t* substream)
 {
-	snd_usb_midi_t* umidi = snd_magic_cast(snd_usb_midi_t, substream->rmidi->private_data, return -ENXIO);
-	usbmidi_in_port_t* port = NULL;
-	int i, j;
-
-	for (i = 0; i < MIDI_MAX_ENDPOINTS; ++i)
-		if (umidi->endpoints[i].in)
-			for (j = 0; j < 0x10; ++j)
-				if (umidi->endpoints[i].in->ports[j].substream == substream) {
-					port = &umidi->endpoints[i].in->ports[j];
-					break;
-				}
-	if (!port)
-		return -ENXIO;
-	substream->runtime->private_data = port;
 	return 0;
 }

@@ -475,9 +467,6 @@

 static void snd_usbmidi_input_trigger(snd_rawmidi_substream_t* substream, int up)
 {
-	usbmidi_in_port_t* port = (usbmidi_in_port_t*)substream->runtime->private_data;
-
-	port->active = up;
 }

 static snd_rawmidi_ops_t snd_usbmidi_output_ops = {




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] USB MIDI bugs

[Martin Langer]

On Mon, Nov 11, 2002 at 09:15:14AM +0100, Clemens Ladisch wrote:
> 
> This fixes sequencer input from USB MIDI. Both usbmidi.c and seq_midi.c
> thought they could use substream->runtime->private_data for themselves.
> 
> Additionally, interrupt transfer resubmissions for kernels before 2.5.45
> are removed again.
> 

Thanks, Clemens! MK-249C is running fine again.

martin


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] USB MIDI bugs

[Fernando Pablo Lopez-Lezcano]

> This fixes sequencer input from USB MIDI. Both usbmidi.c and seq_midi.c
> thought they could use substream->runtime->private_data for themselves.

Thanks! sequencer input is now working on Muse (both 0.5 and 0.6
versions)! Regretfully output seems to not work now :-(

If I turn on debugging in Muse I can see the input events (note on and
note off) being accepted and then the attempt to send them to the output
that fails with this error:

MidiAlsaDevice::putEvent(): midi write error, returns -19 expected 28:
No such device

This is the printout of the received event:
MidiInput: port:0 chan:0 type:0x90 a=58 b=56

and the output event that precedes the error message:
MidiOut: MidiAlsa: port:0 chan:0 type:0x90 a=58 b=56

There are no error printed when Muse subscribes to the input and output
ports. I'll see if I can repeat the error with some other software
package. 

Thanks again for all your help!
-- Fernando




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] USB MIDI bugs

[Fernando Pablo Lopez-Lezcano]

> > This fixes sequencer input from USB MIDI. Both usbmidi.c and seq_midi.c
> > thought they could use substream->runtime->private_data for themselves.
> 
> Thanks! sequencer input is now working on Muse (both 0.5 and 0.6
> versions)! Regretfully output seems to not work now :-(
> 
> If I turn on debugging in Muse I can see the input events (note on and
> note off) being accepted and then the attempt to send them to the output
> that fails with this error:
> 
> MidiAlsaDevice::putEvent(): midi write error, returns -19 expected 28:
> No such device
> 
> This is the printout of the received event:
> MidiInput: port:0 chan:0 type:0x90 a=58 b=56
> 
> and the output event that precedes the error message:
> MidiOut: MidiAlsa: port:0 chan:0 type:0x90 a=58 b=56
> 
> There are no error printed when Muse subscribes to the input and output
> ports. I'll see if I can repeat the error with some other software
> package. 

Pmidi 1.5.4 manages to send to both outputs through alsa. 

But the exact same Muse was working before (I mean before the big
changes that have happened in usb and midi). Has anything changed in the
API? I would imagine that it should keep working with the new version. 

-- Fernando




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] USB MIDI bugs

[Clemens Ladisch]

Fernando Pablo Lopez-Lezcano wrote:
> > Thanks! sequencer input is now working on Muse (both 0.5 and 0.6
> > versions)! Regretfully output seems to not work now :-(
> >
> > If I turn on debugging in Muse I can see the input events (note on and
> > note off) being accepted and then the attempt to send them to the output
> > that fails with this error:
> >
> > MidiAlsaDevice::putEvent(): midi write error, returns -19 expected 28:
> > No such device
>
> Pmidi 1.5.4 manages to send to both outputs through alsa.

Both Muse and pmidi use the sequencer API, so, in theory, both should
work.

> But the exact same Muse was working before (I mean before the big
> changes that have happened in usb and midi). Has anything changed in the
> API?

No, not in the API.

And the error (19 = ENODEV) is rather strange. This isn't returned by the
sequencer API AFAIK (not even if the destination device doesn't exist), so
I'd guess that the sequencer handle got closed somehow.


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: bugs in usb midi alsa code?

[Clemens Ladisch]

Fernando Pablo Lopez-Lezcano wrote:
> > OSS:         rawmidi -v -I /dev/midix
>
>   ./rawmidi -v -I /dev/midi1 --> works fine
>
> > ALSA direct: rawmidi -v -I /dev/snd/midiCxD0
>
>   ./rawmidi -v -I /dev/snd/midiC1D0 --> works fine

These two tests access the driver directly, without going through the ALSA
library, so I'll assume that the driver itself works fine.

> > ALSA Lib:    rawmidi -v -i hw:x,0
>
> ./rawmidi -v -i hw:1,0
> Using:
> Input: device hw:1,0
> Output: NONE
> ALSA lib rawmidi.c:247:(snd_rawmidi_open_conf) symbol _snd_rawmidi_hw_open
> is not defined inside (null)
> snd_rawmidi_open hw:1,0 failed: -6
> Closing
>
> > ALSA Lib:    rawmidi -v -i hw:x,0,0
>
> Same as the previous test.

The ALSA lib is not able to load and call a function from librawmidi.
There seems to be something wrong with your ALSA configuration.
>From the error message I would deduce that there is a rawmidi_type
definition in .asoundrc or /etc/asound.conf or /usr/share/alsa/alsa.conf
which lacks the "lib" key, but I'm not sure about this.
You might try recompiling and installing the alsa-lib package, or
temporarily removing the config files mentioned above.


HTH
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

Re: bugs in usb midi alsa code?

[Werner Schweer]

On Thursday 07 November 2002 09:10, Clemens Ladisch wrote:
> Fernando Pablo Lopez-Lezcano wrote:
> > OSS emulation (raw midi interface):
> >   Midi input and output works fine on the first port,
> > ALSA:
> >   input does not seem to work at all.
>
> Werner Schweer wrote:
> > same on my Roland/Edirol UA100 (audio + 2 midi ports).
>
> Martin Langer wrote:
> > last but not least: same on my Evolution MK-249C keyboard
>
> I don't think the bug is in the snd-usb-audio driver because OSS input
> seems to be working.
>
> Please try the following with the rawmidi program in alsa-lib/test:
> OSS:         rawmidi -v -I /dev/midix
> ALSA direct: rawmidi -v -I /dev/snd/midiCxD0
> ALSA Lib:    rawmidi -v -i hw:x,0
> ALSA Lib:    rawmidi -v -i hw:x,0,0
>
> Did you update alsa-lib together with alsa-kernel? Are you sure you have
> the correct version of libasound installed, and your programs are using
> it?

My System: Roland UA100 usb audio/midi device; ALSA cvs from today (saturday)
(driver + lib), new compiled app

I'm using devfs and when i switch on the ua100 i get the following
messages:

      hub.c: new USB device 00:1d.0-2, assigned address 4
      snd-usb-midi: created 3 output and 3 input ports
      devfs_register(unknown): could not append to parent, err: -17
      devfs_register(unknown): could not append to parent, err: -17
      devfs_register(unknown): could not append to parent, err: -17
      devfs_register(unknown): could not append to parent, err: -17

err -17 -> file exists
And really there is a /dev/sound/unknown (major/minor 14/18).

Recording from /dev/snd/midiC1D0 ("cat /dev/snd/midiC1D0") --> works.
(Only one midi port is visible).
ALSA Lib:    rawmidi -v -i hw:x,0           --> works
ALSA Lib:    rawmidi -v -i hw:x,0,0         --> works

Recording from alsa sequencer ports of UA100 did not work.
With older version of ALSA i got the midi ports on the UA100 working but
not the audio part.

What my app does is:

      snd_seq_port_subscribe_t* subs;
      snd_seq_port_subscribe_alloca(&subs);
      snd_seq_port_subscribe_set_dest(subs, &musePort);
      snd_seq_port_subscribe_set_sender(subs, &adr);
      int error = snd_seq_subscribe_port(alsaSeq, subs);

But no events are arriving from subscribed input port. This worked for previous
ALSA versions.

cat /proc/asound/seq/clients says:

Client info
  cur  clients : 4
  peak clients : 4
  max  clients : 192

Client   0 : "System" [Kernel]
  Port   0 : "Timer" (Rwe-)
  Port   1 : "Announce" (R-e-)
    Connecting To: 128:0
Client  72 : "External MIDI 1" [Kernel]
  Port   0 : "UA-100 Port 0" (RWeX)
    Connecting To: 128:0
    Connected From: 128:0
  Port   1 : "UA-100 Port 1" (RWeX)
    Connecting To: 128:0
    Connected From: 128:0
  Port   2 : "UA-100 Port 2" (RWeX)
    Connecting To: 128:0
    Connected From: 128:0
Client 128 : "MusE Sequencer" [User]
  Port   0 : "MusE Port 0" (RWe-)
    Connecting To: 72:0, 72:1, 72:2
    Connected From: 0:1, 72:0, 72:1, 72:2
  Output pool :
    Pool size          : 500
    Cells in use       : 0
    Peak cells in use  : 0
    Alloc success      : 0
    Alloc failures     : 0
  Input pool :
    Pool size          : 200
    Cells in use       : 0
    Peak cells in use  : 9
    Alloc success      : 9
    Alloc failures     : 0
Client 129 : "organ" [User]
  Port   0 : "organ-1" (-We-)
  Input pool :
    Pool size          : 200
    Cells in use       : 0
    Peak cells in use  : 1
    Alloc success      : 68
    Alloc failures     : 0




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf