Re: USB Audio/Midiman - partial success

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Fedor G. Pikus wrote:
> On Fri, 20 Sep 2002, Clemens Ladisch wrote:
> 
> >       case EXPIRED:
> >               snd_printd("capture read error (DMA or IRQ trouble?)\n");
> >               err = -EIO;
> >
> > Are you _really_ sure you have recompiled the entire alsa-driver package
> > with debug output, installed it correctly, and there's nothing in the log?
> 
> kernel: ALSA ../alsa-kernel/core/pcm_lib.c:2212: EXPIRED in snd_pcm_lib_read1 ...

The "capture read error" message should have been printed.
I guess debug output isn't really enabled for your ALSA core.

> when everything works ok it gets interrupted but when I'm trying to record
> at 96000 it does not. Where do I look now?

Apparently, the USB packets don't arrive, or the driver thinks they don't
arrive, or the driver doesn't like them and throws them away.

In theory, snd_complete_urb is called when some data has been received
from the device, and this function calls retire_capture_urb. Please check
whether those functions are really called.


HTH
Clemens


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

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Mon, 23 Sep 2002 21:14:36 -0700 (PDT),
Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> 
> On Mon, 23 Sep 2002, Clemens Ladisch wrote:
> > Fedor G. Pikus wrote:
> > > On Fri, 20 Sep 2002, Clemens Ladisch wrote:
> > >
> > > >       case EXPIRED:
> > > >               snd_printd("capture read error (DMA or IRQ trouble?)\n");
> > > >               err = -EIO;
> > > >
> > > > Are you _really_ sure you have recompiled the entire alsa-driver package
> > > > with debug output, installed it correctly, and there's nothing in the log?
> > >
> > > kernel: ALSA ../alsa-kernel/core/pcm_lib.c:2212: EXPIRED in snd_pcm_lib_read1 ...
> >
> > The "capture read error" message should have been printed.
> > I guess debug output isn't really enabled for your ALSA core.
> I also thought so when I found that snd_printd. I use cvscompile which
> does add --with-debug-full to configure (and I tried running configure manually
> with this switch), --with-debug=full must not be working (I noticed earlier
> "full" does not generate the messages which are generated by "detect", so
> I'm not sure what "full" actually does).

well, snd_printdd() is activated only when --with-debug=detect is
used.  but snd_printd() is activated even with --with-debug=full.

yeah, this debug option looks confusing.  everybody would think that
full is full, but not fulfilled in reality :)

> > > when everything works ok it gets interrupted but when I'm trying to record
> > > at 96000 it does not. Where do I look now?
> >
> > In theory, snd_complete_urb is called when some data has been received
> > from the device, and this function calls retire_capture_urb. Please check
> > whether those functions are really called.
> They do get called, it goes like this:
> pcm_lib.c:2168 unlocked IRQ, waiting for 10 seconds
> snd_complete_urb called
> retire_capture_urb called
> retire_capture_urb done
> snd_complete_urb exits (by exiting through the bottom, never through return)
> ... repeat about 740 times the above 4 lines ...
> pcm_lib.c:2170 timed out after 10 seconds

does it means that complete is called _after_ the 10-sec-wait message?
could you tell me the function (line) corresponding to the original
source (the line is shifted so i cannot see where it is).


Takashi


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

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Tue, 24 Sep 2002 08:42:03 -0700 (PDT),
Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> 
> On Tue, 24 Sep 2002, Takashi Iwai wrote:
> > At Mon, 23 Sep 2002 21:14:36 -0700 (PDT),
> > Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> > >
> > > On Mon, 23 Sep 2002, Clemens Ladisch wrote:
> > > > In theory, snd_complete_urb is called when some data has been received
> > > > from the device, and this function calls retire_capture_urb. Please check
> > > > whether those functions are really called.
> > > They do get called, it goes like this:
> > > pcm_lib.c:2168 unlocked IRQ, waiting for 10 seconds
> > > snd_complete_urb called
> > > retire_capture_urb called
> > > retire_capture_urb done
> > > snd_complete_urb exits (by exiting through the bottom, never through return)
> > > ... repeat about 740 times the above 4 lines ...
> > > pcm_lib.c:2170 timed out after 10 seconds
> >
> > does it means that complete is called _after_ the 10-sec-wait message?
> > could you tell me the function (line) corresponding to the original
> > source (the line is shifted so i cannot see where it is).
> 
> No, snd_complete_urb is called 740 times during the 10-second wait:
> 
> spin_unlock_irq(&runtime->lock);
> <---- print "unlocked IRQ"
> if (schedule_timeout(10 * HZ) == 0) { <---- 10 second wait while "snd_complete_urb" messages scroll by in the log
>         spin_lock_irq(&runtime->lock);
>         <----- print "timed out"
>         state = runtime->status->state == SNDRV_PCM_STATE_SUSPENDED ? SUSPENDED : EXPIRED;
>         break;
> }

then the complete callback is called properly but likely
snd_pcm_period_elapsed() is not called.
can you check in retire_capture_urb() whether subs->transfer_done is
incremented and snd_pcm_period_elapsed is called properly?
if it's not incremented, that means either iso frame is still active
or the obtained frame length is zero.


btw, to be sure, which version of usbaudio.c are you using?


Takashi


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

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Tue, 24 Sep 2002 20:03:54 -0700 (PDT),
Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> 
> > then the complete callback is called properly but likely
> > snd_pcm_period_elapsed() is not called.
> 
> That's right, it's not called:
> for (i = 0; i < urb->number_of_packets; i++) {
>         cp = (unsigned char *)urb->transfer_buffer + urb->iso_frame_desc[i].offset;
>         if (urb->iso_frame_desc[i].status) /* active? hmm, skip this */
>                 continue;

could you check what value is stored in the status field?
i guess some negative value, which represents an error.

and, how does the driver act if you skip this check?


ciao,

Takashi


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

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Fedor G. Pikus wrote:
> On Wed, 25 Sep 2002, Takashi Iwai wrote:
> > At Tue, 24 Sep 2002 20:03:54 -0700 (PDT),
> > Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> > >
> > > > then the complete callback is called properly but likely
> > > > snd_pcm_period_elapsed() is not called.
> > >
> > > That's right, it's not called:
> > > for (i = 0; i < urb->number_of_packets; i++) {
> > >         cp = (unsigned char *)urb->transfer_buffer + urb->iso_frame_desc[i].offset;
> > >         if (urb->iso_frame_desc[i].status) /* active? hmm, skip this */
> > >                 continue;
> >
> > could you check what value is stored in the status field?
> > i guess some negative value, which represents an error.
> Always -75.

-75 = -EOVERFLOW = babble

I think this indicates that the device sends more data than the driver
expects. Probably the transfer buffer size is calculated for some lower
sample rate?


HTH
Clemens



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

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Thu, 26 Sep 2002 09:47:50 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Fedor G. Pikus wrote:
> > On Wed, 25 Sep 2002, Takashi Iwai wrote:
> > > At Tue, 24 Sep 2002 20:03:54 -0700 (PDT),
> > > Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> > > >
> > > > > then the complete callback is called properly but likely
> > > > > snd_pcm_period_elapsed() is not called.
> > > >
> > > > That's right, it's not called:
> > > > for (i = 0; i < urb->number_of_packets; i++) {
> > > >         cp = (unsigned char *)urb->transfer_buffer + urb->iso_frame_desc[i].offset;
> > > >         if (urb->iso_frame_desc[i].status) /* active? hmm, skip this */
> > > >                 continue;
> > >
> > > could you check what value is stored in the status field?
> > > i guess some negative value, which represents an error.
> > Always -75.
> 
> -75 = -EOVERFLOW = babble
> 
> I think this indicates that the device sends more data than the driver
> expects. Probably the transfer buffer size is calculated for some lower
> sample rate?

it can be.

what shows /proc/asound/card0/stream* if the corresponding pcm is
running?  this will show the current interface and altset.

also, the transferred size for each packet is defined as
subs->curpacksize (in bytes) and subs->curframesize (in frames).
please check these values via printk.


ciao,

Takashi


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

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

At Thu, 26 Sep 2002 12:42:32 -0700 (PDT),
Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> 
> This is the right interface and altset (I was capturing with -r 96000 -f
> S16_LE). Two more files from proc about this pcm:
> pcm0c/sub0/hw_params
> access: RW_INTERLEAVED
> format: S16_LE
> subformat: STD
> channels: 2
> rate: 30464 (96000/1)
        ^^^^^^^^^^^^^^^
ah, this is the problem.

could you try the attached patch?


thanks,

Takashi

[-- Attachment #2: audio-rate-fix.dif --]
[-- Type: application/octet-stream, Size: 1120 bytes --]

Index: alsa-kernel/usb/usbaudio.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.13
diff -u -r1.13 usbaudio.c
--- alsa-kernel/usb/usbaudio.c	30 Sep 2002 13:38:00 -0000	1.13
+++ alsa-kernel/usb/usbaudio.c	2 Oct 2002 13:41:50 -0000
@@ -1009,6 +1009,7 @@
 	}
 	/* if endpoint has sampling rate control, set it */
 	if (fmt->attributes & EP_CS_ATTR_SAMPLE_RATE) {
+		int crate;
 		data[0] = runtime->rate;
 		data[1] = runtime->rate >> 8;
 		data[2] = runtime->rate >> 16;
@@ -1026,8 +1027,11 @@
 				   dev->devnum, subs->interface, fmt->altsetting, ep);
 			return err;
 		}
-		runtime->rate = data[0] | (data[1] << 8) | (data[2] << 16);
-		// printk("ok, getting back rate to %d\n", runtime->rate);
+		crate = data[0] | (data[1] << 8) | (data[2] << 16);
+		if (crate != runtime->rate) {
+			snd_printk(KERN_WARNING, "current rate %d is different from the runtime rate %d\n", crate, runtime->rate);
+			// runtime->rate = crate;
+		}
 	}
 	/* always fill max packet size */
 	if (fmt->attributes & EP_CS_ATTR_FILL_MAX)

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Thu, 3 Oct 2002 23:02:07 -0700 (PDT),
Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> 
> Could you explay me what does it do? It sets "crate" what used to be
> "runtile->rate" but then it does not do anything with crate?

it checks the requested rate value has been really set on the
interface.  but it seems ok even the momentary value doesn't match, so
now only print warning.

> BTW, I get stuff like this in the log:
>  ALSA ../alsa-kernel/usb/usbaudio.c:1025: <4>ALSA ../alsa-kernel/usb/usbaudio.c:1025: <4>ALSA ../alsa-kernel/usb/usbaudio.c:1025: <4>ALSA ../alsa-kernel/usb/usbaudio.c:1025: ... more of the same ...

it's a typo (comma between KERN_* and the format string).
fixed on cvs now.


ciao,

Takashi


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

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Fedor G. Pikus wrote:
> > Fedor G. Pikus wrote:
> > > > > > > arecord: pcm_read:1049: read error: Input/output error
> > >
> > > Still nothing in the log, even with --with-debug=full
> 
> I built arecord and libasound with debug and went into it with gdb.
> I traced it to the function static snd_pcm_sframes_t snd_pcm_hw_readi(...)
> in pcm_hw.c line 525. There, it makes a call to
> result = ioctl(fd, SNDRV_PCM_IOCTL_READI_FRAMES, &xferi);
> and pauses for a few seconds. When ioctl returns, result == -1,
> size == 5, xferi == {result = -5, buf = 0x805a470, frames = 4096},
> and errno == 5 (EIO according to asm/include.h, the man page for ioctl does
> not even list it among valid error codes). The function immediately returns,
> and arecord exits.

If the pause is 10 seconds, the error may have been returned by the following
code in snd_pcm_lib_read1:

	if (schedule_timeout(10 * HZ) == 0) {
		state = ... EXPIRED;
		break;
	}
	...
	case EXPIRED:
		snd_printd("capture read error (DMA or IRQ trouble?)\n");
		err = -EIO;

Or is the pause 5 seconds (the timeout of usb_set_interface)?

	if (usb_set_interface(dev, subs->interface, fmt->altset_idx) < 0) {
		snd_printk(KERN_ERR "%d:%d:%d: usb_set_interface failed\n",
			   dev->devnum, subs->interface, fmt->altsetting);
		return -EIO;
	}

Are you _really_ sure you have recompiled the entire alsa-driver package
with debug output, installed it correctly, and there's nothing in the log?

Please try inserting the line

	snd_printk(KERN_ERR "now calling usb_set_interface ...\n");

immediately before the line with usb_set_interface in usbaudio.c. This
message must always be visible in the log.


HTH
Clemens


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

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Fedor G. Pikus wrote:
> > > It happens with either S16_LE or S24_3LE if the rate is 96000.
> > > It does not happen right away, but after several seconds.
>
> With raw the file length is 0. With wav is was probably just the header,
> the length is right, 44.

So it doesn't record anything, and needs several seconds to realize this.

> > > > > arecord: pcm_read:1049: read error: Input/output error
>
> Still nothing in the log, even with --with-debug=full

Please try the -v option of arecord. (But I doubt this will show anything
useful. I'm telling you this only to hide the fact that I don't have any
clue what is going on. ;-)


Regards,
Clemens



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Fedor G. Pikus wrote:
> On Mon, 16 Sep 2002, Clemens Ladisch wrote:
> > > arecord: pcm_read:1049: read error: Input/output error
> >
> > Anything in /var/log/mesages?
> > Does it happen with 24 bits, too?
> > Is the data in the file correct (as far as is has been recorded)?
>
> Nothing in the log at all. I can bump up the debug level for usb-snd-audio,
> what would be helpful, if anything?

I had expected some messages from the USB subsystem.
Anyway, enabling debug output would help.

> It happens with either S16_LE or S24_3LE if the rate is 96000.
> It does not happen right away, but after several seconds. There is something
> in the file (i.e. the length is not 0) but it's not correct (i.e. any
> tool I try to send this file to reports that it's corrupt, starting with aplay).

arecord didn't set the length when it was interrupted. Please try to
record a raw file.


HTH
Clemens



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Fedor G. Pikus wrote:
> Latest TOT drivers from CVS, compiled, installed, rebooted WITH DUO OFF.
> Ran /etc/init.d/alsasound start, turned Duo on.
> Check /proc/asound/card1/stream0 - everything is there (I attached the file)
>
> Do /etc/init.d/alsasound stop, then /etc/init.d/alsasound start - only 2
> interfaces are present. Ok, let's see what /etc/init.d/alsasound stop
> does not unload... 2 modules, audio and soundcore. Do stop, unload those,
> do start - all 5 interfaces are there. Now I see what's the problem with
> booting while Duo is on: as soon as USB controller is initialized, hotplug
> kicks in and loads audio module.

"audio" is the OSS driver from the kernel. As you've seen, having two
drivers compete for one device isn't desirable. Usually, the OSS drivers
should be disabled when using ALSA.

Either
- deactivate the OSS drivers and recompile the kernel, or
- delete audio.o, or
- add audio to the blacklist file in /etc/hotplug.

> Now, can someone tell me why this fails:
> arecord -f S16_LE -r 96000 -c 2 -D hw:1,0 /tmp/test.wav
> Recording WAVE '/tmp/test.wav' : Signed 16 bit Little Endian, Rate 96000 Hz, Stereo
> arecord: pcm_read:1049: read error: Input/output error
> (after several seconds).

Anything in /var/log/mesages?
Does it happen with 24 bits, too?
Is the data in the file correct (as far as is has been recorded)?


HTH
Clemens



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

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Fedor G. Pikus wrote:
> > > Why doesn't 48KHz work, and where are higher rates, where is 24bit
> > > recording?
> >
> > These features should be available if the device has correct descriptors.
> > Please post the output of lsusb.
> 
> Wow, that's a long output. Here is is:
> ...

Let's make a nice table from this:

intf alt endpt  rate  bits
0    0   (control, pcm0)
1    0
1    3   out 3  8-48  24
1    4   out 3  8-44  16
2    0
2    3   in 5   8-48  24
2    4   in 5   8-44  16
3    0   (control, pcm1)
4    0
4    1   out 3  88-96 24
4    2   out 3  88-96 16
4    3   out 3  8-48  24
4    4   out 3  8-48  16
5    0
5    1   in 5   88-96 24
5    2   in 5   88-96 16
5    3   in 5   8-48  24
5    4   in 5   8-48  16

The good news is that 24 bits (S24_3LE) should work fine (up to 48 kHz).

The bad news is that this device appears to be broken by design.

There are two PCM devices, but both use the same endpoints.
Consequently, when the driver wants to record from pcm1, it reads
from endpoint 5, but the USB driver then searches for descriptors for
EP 5 and finds those from pcm0 which do not have information about
88.2/96 kHz or 48 kHz at 16 bits.

It may be possible to fake better descriptors by adding a quirk and
some code to the snd-usb-audio driver. I'm not sure whether the host
controller driver had to be aware of the fake, too -- currently, the
alternate settings 1 and 2 wouldn't be found, and wMaxPacketSize
would be too small for 96 kHz.

The two PCM devices cannot be used at the same time anyway, so I think
creating a quirk for interface 0 which says "ignore this" could work.
Takashi, any comments?


Regards,
Clemens


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Mon, 09 Sep 2002 19:46:21 +0200,
Clemens Ladisch wrote:
> 
> Fedor G. Pikus wrote:
> > > > Why doesn't 48KHz work, and where are higher rates, where is 24bit
> > > > recording?
> > >
> > > These features should be available if the device has correct descriptors.
> > > Please post the output of lsusb.
> > 
> > Wow, that's a long output. Here is is:
> > ...
> 
> Let's make a nice table from this:
> 
> intf alt endpt  rate  bits
> 0    0   (control, pcm0)
> 1    0
> 1    3   out 3  8-48  24
> 1    4   out 3  8-44  16
> 2    0
> 2    3   in 5   8-48  24
> 2    4   in 5   8-44  16
> 3    0   (control, pcm1)
> 4    0
> 4    1   out 3  88-96 24
> 4    2   out 3  88-96 16
> 4    3   out 3  8-48  24
> 4    4   out 3  8-48  16
> 5    0
> 5    1   in 5   88-96 24
> 5    2   in 5   88-96 16
> 5    3   in 5   8-48  24
> 5    4   in 5   8-48  16
 
ah, that's really better to understand :)
is there any good text-format tool for usb descriptors except for
humanbeing?

> The good news is that 24 bits (S24_3LE) should work fine (up to 48 kHz).
> 
> The bad news is that this device appears to be broken by design.
> 
> There are two PCM devices, but both use the same endpoints.
> Consequently, when the driver wants to record from pcm1, it reads
> from endpoint 5, but the USB driver then searches for descriptors for
> EP 5 and finds those from pcm0 which do not have information about
> 88.2/96 kHz or 48 kHz at 16 bits.
 
usb-audio driver assigns the pcm stream per interface and holds the
format table for each stream statically, so theoretically, the driver
will be able to find the configuration.  but this doesn't help anyway
as you pointed if both use the same endpoint...

> It may be possible to fake better descriptors by adding a quirk and
> some code to the snd-usb-audio driver. I'm not sure whether the host
> controller driver had to be aware of the fake, too -- currently, the
> alternate settings 1 and 2 wouldn't be found, and wMaxPacketSize
> would be too small for 96 kHz.

it seems fine: 576 = 96 * 6 and 384 = 96 * 4 ?
 
> The two PCM devices cannot be used at the same time anyway, so I think
> creating a quirk for interface 0 which says "ignore this" could work.
> Takashi, any comments?

i think implementing a semaphore (or flag) for each endpoint would be
better, so that the driver can find generally double-endpoints
problem.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: USB Audio/Midiman - partial success

[Clemens Ladisch]

Takashi Iwai wrote:
> is there any good text-format tool for usb descriptors except for
> humanbeing?

The /proc/asound/card?... information of snd-usb-audio ;-)

Fedor, it would be interesting to see how much got parsed with uhci.

> > There are two PCM devices, but both use the same endpoints.
> ...
> > It may be possible to fake better descriptors by adding a quirk and
> > some code to the snd-usb-audio driver. I'm not sure whether the host
> > controller driver had to be aware of the fake, too -- currently, the
> > alternate settings 1 and 2 wouldn't be found, and wMaxPacketSize
> > would be too small for 96 kHz.
>
> it seems fine: 576 = 96 * 6 and 384 = 96 * 4 ?

In interfaces 1/2, wMaxPacketSize isn't greater than 288. But I've just
realized that usb.c looks at all interfaces to determine the maximum, so
this isn't an issue.

> > The two PCM devices cannot be used at the same time anyway, so I think
> > creating a quirk for interface 0 which says "ignore this" could work.
> > Takashi, any comments?
>
> i think implementing a semaphore (or flag) for each endpoint would be
> better, so that the driver can find generally double-endpoints
> problem.

I cannot imagine anybody else would be stupid enough to design a device
with double endpoints. But then I didn't imagine Midiman would, either.
Oh well, Murphy's Law ...  :-(

Currently, both uhci and usb-uhci break in interesting ways, and I'm not
sure this could be prevented by some workaround in snd-usb-audio. I have
the feeling that all host controller drivers ([usb-]uhci, ohci, ehci,
...), or usb.c, would have to be patched to work around the problem. But I
didn't write the USB subsystem, nor do I have the device, so feel free to
ignore my opinion. :)


Regards,
Clemens



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
Clemens Ladisch wrote:
> 
> > > The two PCM devices cannot be used at the same time anyway, so I think
> > > creating a quirk for interface 0 which says "ignore this" could work.
> > > Takashi, any comments?
> >
> > i think implementing a semaphore (or flag) for each endpoint would be
> > better, so that the driver can find generally double-endpoints
> > problem.
> 
> I cannot imagine anybody else would be stupid enough to design a device
> with double endpoints. But then I didn't imagine Midiman would, either.
> Oh well, Murphy's Law ...  :-(
 
I found that M-Audio quattro has the same problem.
the same endpoints are shared among different interfaces.  sigh...


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: USB Audio/Midiman - partial success

[Patrick Shirkey]

Takashi Iwai wrote:
> At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> Clemens Ladisch wrote:
> 
>>>>The two PCM devices cannot be used at the same time anyway, so I think
>>>>creating a quirk for interface 0 which says "ignore this" could work.
>>>>Takashi, any comments?
>>>
>>>i think implementing a semaphore (or flag) for each endpoint would be
>>>better, so that the driver can find generally double-endpoints
>>>problem.
>>
>>I cannot imagine anybody else would be stupid enough to design a device
>>with double endpoints. But then I didn't imagine Midiman would, either.
>>Oh well, Murphy's Law ...  :-(
> 
>  
> I found that M-Audio quattro has the same problem.
> the same endpoints are shared among different interfaces.  sigh...
> 

I think a possible reason for this in the quattro is to ensure that 
customers eventually have to upgrade to a next gen device. From what I 
remember the win drivers will only allow stereo i/o at 96Khz. Even 
though it has 4 channels or 2 stereo devices.

If there was a Midiman rep on this list they could rebute that ;P



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/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: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
Clemens Ladisch wrote:
> 
> > > The two PCM devices cannot be used at the same time anyway, so I think
> > > creating a quirk for interface 0 which says "ignore this" could work.
> > > Takashi, any comments?
> >
> > i think implementing a semaphore (or flag) for each endpoint would be
> > better, so that the driver can find generally double-endpoints
> > problem.
> 
> I cannot imagine anybody else would be stupid enough to design a device
> with double endpoints. But then I didn't imagine Midiman would, either.
> Oh well, Murphy's Law ...  :-(

since many (at least plural :) devices have this problem, i changed
the usbaudio code slightly.  now a pcm stream is created per endpoint
instead of interface.

on this version, m-audio's device should have one (for duo) or two
(for quattro) pcm devices.

please let me know if any problems arise with this change.


ciao,

Takashi


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

Re: USB Audio/Midiman - partial success

[Patrick Shirkey]

Takashi Iwai wrote:
> At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> Clemens Ladisch wrote:
> 
>>>>The two PCM devices cannot be used at the same time anyway, so I think
>>>>creating a quirk for interface 0 which says "ignore this" could work.
>>>>Takashi, any comments?
>>>
>>>i think implementing a semaphore (or flag) for each endpoint would be
>>>better, so that the driver can find generally double-endpoints
>>>problem.
>>
>>I cannot imagine anybody else would be stupid enough to design a device
>>with double endpoints. But then I didn't imagine Midiman would, either.
>>Oh well, Murphy's Law ...  :-(
> 
> 
> since many (at least plural :) devices have this problem, i changed
> the usbaudio code slightly.  now a pcm stream is created per endpoint
> instead of interface.
> 
> on this version, m-audio's device should have one (for duo) or two
> (for quattro) pcm devices.
> 
> please let me know if any problems arise with this change.
> 

Now you definitely deserve a medal. A preliminary test with jack 
provides crystal clear sound.

You da man You da muthafucken man. Please pat yourself on the back from me.

Now I have 2 streams in /proc/asound/card2/

The final test is getting all four channels to play and record at the 
same time. If we can do that using ALSA all other platforms can eat our 
dust. From my tests before this breakthrough it seemed possible.





-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: USB Audio/Midiman - partial success

[Patrick Shirkey]

Takashi Iwai wrote:
> At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> Clemens Ladisch wrote:
> 
>>>>The two PCM devices cannot be used at the same time anyway, so I think
>>>>creating a quirk for interface 0 which says "ignore this" could work.
>>>>Takashi, any comments?
>>>
>>>i think implementing a semaphore (or flag) for each endpoint would be
>>>better, so that the driver can find generally double-endpoints
>>>problem.
>>
>>I cannot imagine anybody else would be stupid enough to design a device
>>with double endpoints. But then I didn't imagine Midiman would, either.
>>Oh well, Murphy's Law ...  :-(
> 
> 
> since many (at least plural :) devices have this problem, i changed
> the usbaudio code slightly.  now a pcm stream is created per endpoint
> instead of interface.
> 
> on this version, m-audio's device should have one (for duo) or two
> (for quattro) pcm devices.
> 
> please let me know if any problems arise with this change.
> 

FYI: I have found that using the quattro with jack is rock solid when 
only accessing one of the pcms at a time at 48khz even as normal user.

But switch to a higher sample rate and/or 4 channels(with root 
priveledges and lowlatency scheduling on) and different things happen:

----
  jackd -v -d alsa -d quattro1 -r 96000 -p 192
jackd 0.37.2
Copyright 2001-2002 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

10691 waiting for signals
creating alsa driver ... quattro1|192|2|96000|swmon
ALSA lib pcm_hw.c:398:(snd_pcm_hw_prepare) SNDRV_PCM_IOCTL_PREPARE 
failed: Invalid argument
ALSA: cannot set hardware parameters for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
jack main caught signal 15
----
jackd -v -d alsa -d q4b -r 48000 -p 3072
jackd 0.37.2
Copyright 2001-2002 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

10728 waiting for signals
creating alsa driver ... q4b|3072|2|48000|swmon
new client: alsa_pcm, id = 1 type 1 @ 0x8068078 fd = 14
port alsa_pcm:in_1 buf shm key 0x53ff306d at offset 12288 bi = 0x8067448
registered port alsa_pcm:in_1, offset = 12288
port alsa_pcm:in_2 buf shm key 0x53ff306d at offset 24576 bi = 0x8067458
registered port alsa_pcm:in_2, offset = 24576
port alsa_pcm:in_3 buf shm key 0x53ff306d at offset 36864 bi = 0x8067468
registered port alsa_pcm:in_3, offset = 36864
port alsa_pcm:in_4 buf shm key 0x53ff306d at offset 49152 bi = 0x8067478
registered port alsa_pcm:in_4, offset = 49152
registered port alsa_pcm:out_1, offset = 0
registered port alsa_pcm:out_2, offset = 0
registered port alsa_pcm:out_3, offset = 0
registered port alsa_pcm:out_4, offset = 0
-- jack_rechain_graph():
client alsa_pcm: inprocess client, execution_order=0.


**** alsa_pcm: xrun of at least 0.046 msecs



**** alsa_pcm: xrun of at least 0.045 msecs

load = 11.1325 max usecs: 14249.315, spare = 49749.684


**** alsa_pcm: xrun of at least 0.044 msecs

load = 16.6987 max usecs: 14249.315, spare = 49749.684


**** alsa_pcm: xrun of at least 0.043 msecs

load = 19.4754 max usecs: 14241.095, spare = 49757.906
load = 20.8637 max usecs: 14241.095, spare = 49757.906
load = 10.5940 max usecs: 207.489, spare = 63791.512


**** alsa_pcm: xrun of at least 0.045 msecs


load = 16.4347 max usecs: 14256.115, spare = 49742.883
load = 19.3551 max usecs: 14256.115, spare = 49742.883
load = 9.8830 max usecs: 262.911, spare = 63736.090


**** alsa_pcm: xrun of at least 0.043 msecs

load = 16.0698 max usecs: 14243.989, spare = 49755.012
jackd: signal 2 received
jack main caught signal 15

# jackd -v -d alsa -d q4b -r 48000 -p 6144
jackd 0.37.2
Copyright 2001-2002 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

10734 waiting for signals
creating alsa driver ... q4b|6144|2|48000|swmon
new client: alsa_pcm, id = 1 type 1 @ 0x8068078 fd = 14
port alsa_pcm:in_1 buf shm key 0x74529998 at offset 24576 bi = 0x8067448
registered port alsa_pcm:in_1, offset = 24576
port alsa_pcm:in_2 buf shm key 0x74529998 at offset 49152 bi = 0x8067458
registered port alsa_pcm:in_2, offset = 49152
port alsa_pcm:in_3 buf shm key 0x74529998 at offset 73728 bi = 0x8067468
registered port alsa_pcm:in_3, offset = 73728
port alsa_pcm:in_4 buf shm key 0x74529998 at offset 98304 bi = 0x8067478
registered port alsa_pcm:in_4, offset = 98304
registered port alsa_pcm:out_1, offset = 0
registered port alsa_pcm:out_2, offset = 0
registered port alsa_pcm:out_3, offset = 0
registered port alsa_pcm:out_4, offset = 0
-- jack_rechain_graph():
client alsa_pcm: inprocess client, execution_order=0.


**** alsa_pcm: xrun of at least 1.435 msecs



**** alsa_pcm: xrun of at least 0.046 msecs

load = 5.2546 max usecs: 13451.668, spare = 114547.328


**** alsa_pcm: xrun of at least 0.043 msecs

load = 8.6591 max usecs: 15441.339, spare = 112557.664


**** alsa_pcm: xrun of at least 0.042 msecs

load = 10.3614 max usecs: 15441.339, spare = 112557.664


**** alsa_pcm: xrun of at least 0.045 msecs

load = 11.2125 max usecs: 15441.339, spare = 112557.664


**** alsa_pcm: xrun of at least 0.046 msecs

load = 11.6381 max usecs: 15441.339, spare = 112557.664
jackd: signal 2 received
jack main caught signal 15



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Fri, 13 Sep 2002 14:59:40 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> > At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
> > Clemens Ladisch wrote:
> > 
> >>>>The two PCM devices cannot be used at the same time anyway, so I think
> >>>>creating a quirk for interface 0 which says "ignore this" could work.
> >>>>Takashi, any comments?
> >>>
> >>>i think implementing a semaphore (or flag) for each endpoint would be
> >>>better, so that the driver can find generally double-endpoints
> >>>problem.
> >>
> >>I cannot imagine anybody else would be stupid enough to design a device
> >>with double endpoints. But then I didn't imagine Midiman would, either.
> >>Oh well, Murphy's Law ...  :-(
> > 
> > 
> > since many (at least plural :) devices have this problem, i changed
> > the usbaudio code slightly.  now a pcm stream is created per endpoint
> > instead of interface.
> > 
> > on this version, m-audio's device should have one (for duo) or two
> > (for quattro) pcm devices.
> > 
> > please let me know if any problems arise with this change.
> > 
> 
> FYI: I have found that using the quattro with jack is rock solid when 
> only accessing one of the pcms at a time at 48khz even as normal user.

oh, that's bad.  could you show the output of
/proc/asound/card0/stream* ?

> But switch to a higher sample rate and/or 4 channels(with root 
> priveledges and lowlatency scheduling on) and different things happen:
> 
> ----
>   jackd -v -d alsa -d quattro1 -r 96000 -p 192
> jackd 0.37.2
> Copyright 2001-2002 Paul Davis and others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> 
> 10691 waiting for signals
> creating alsa driver ... quattro1|192|2|96000|swmon
> ALSA lib pcm_hw.c:398:(snd_pcm_hw_prepare) SNDRV_PCM_IOCTL_PREPARE 
> failed: Invalid argument
  ^^^^^^^^^^^^^^^^^^^^^^^^
hmm...

> ALSA: cannot set hardware parameters for capture
> ALSA: cannot configure capture channel
> cannot load driver module alsa
> jack main caught signal 15
> ----
> jackd -v -d alsa -d q4b -r 48000 -p 3072
> jackd 0.37.2

did you run jack with 48k immediately after setting 96k?
so, some old configuration is left and this makes the difference.
perhaps this is also the problem once you reported that the driver
works only after once capture runs.


ciao,

Takashi


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

Re: USB Audio/Midiman - partial success

[Patrick Shirkey]

Takashi Iwai wrote:
> At Fri, 13 Sep 2002 14:59:40 +0900,
> Patrick Shirkey wrote:
> 
>>Takashi Iwai wrote:
>>
>>>At Tue, 10 Sep 2002 10:58:34 +0200 (METDST),
>>>Clemens Ladisch wrote:
>>>
>>>
>>>>>>The two PCM devices cannot be used at the same time anyway, so I think
>>>>>>creating a quirk for interface 0 which says "ignore this" could work.
>>>>>>Takashi, any comments?
>>>>>
>>>>>i think implementing a semaphore (or flag) for each endpoint would be
>>>>>better, so that the driver can find generally double-endpoints
>>>>>problem.
>>>>
>>>>I cannot imagine anybody else would be stupid enough to design a device
>>>>with double endpoints. But then I didn't imagine Midiman would, either.
>>>>Oh well, Murphy's Law ...  :-(
>>>
>>>
>>>since many (at least plural :) devices have this problem, i changed
>>>the usbaudio code slightly.  now a pcm stream is created per endpoint
>>>instead of interface.
>>>
>>>on this version, m-audio's device should have one (for duo) or two
>>>(for quattro) pcm devices.
>>>
>>>please let me know if any problems arise with this change.
>>>
>>
>>FYI: I have found that using the quattro with jack is rock solid when 
>>only accessing one of the pcms at a time at 48khz even as normal user.
> 
> 
> oh, that's bad.  could you show the output of
> /proc/asound/card0/stream* ?
> 

Au contraire, It's good. Well it was until I updated alsa-lib and jack. 
I will backout and retest there.

Anyhow.

----
  cat /proc/asound/card2/stream0
M Audio USB AudioSport Quattro (tm) : USB Audio

Playback:
   Status: Stop
   Altset 1
     Format: S16_LE
     Channels: 2
     Endpoint: 3 OUT (ADAPTIVE)
     Rates: 11025, 22050, 44100
   Altset 1
     Format: S24_3LE
     Channels: 2
     Endpoint: 3 OUT (ADAPTIVE)
     Rates: 88200, 96000
   Altset 2
     Format: S24_3LE
     Channels: 2
     Endpoint: 3 OUT (ADAPTIVE)
     Rates: 11025, 22050, 44100, 48000
   Altset 3
     Format: S16_LE
     Channels: 2
     Endpoint: 3 OUT (ADAPTIVE)
     Rates: 11025, 22050, 44100, 48000

Capture:
   Status: Stop
   Altset 1
     Format: S16_LE
     Channels: 2
     Endpoint: 5 IN (SYNC)
     Rates: 11025, 22050, 44100
   Altset 1
     Format: S24_3LE
     Channels: 2
     Endpoint: 5 IN (SYNC)
     Rates: 88200, 96000
   Altset 2
     Format: S24_3LE
     Channels: 2
     Endpoint: 5 IN (SYNC)
     Rates: 11025, 22050, 44100, 48000
   Altset 3
     Format: S16_LE
     Channels: 2
     Endpoint: 5 IN (SYNC)
     Rates: 11025, 22050, 44100, 48000


  cat /proc/asound/card2/stream1
M Audio USB AudioSport Quattro (tm) : USB Audio #1

Playback:
   Status: Stop
   Altset 1
     Format: S24_3LE
     Channels: 2
     Endpoint: 4 OUT (ADAPTIVE)
     Rates: 88200, 96000
   Altset 2
     Format: S24_3LE
     Channels: 2
     Endpoint: 4 OUT (ADAPTIVE)
     Rates: 11025, 22050, 44100, 48000
   Altset 3
     Format: S16_LE
     Channels: 2
     Endpoint: 4 OUT (ADAPTIVE)
     Rates: 11025, 22050, 44100, 48000

Capture:
   Status: Stop
   Altset 1
     Format: S24_3LE
     Channels: 2
     Endpoint: 6 IN (SYNC)
     Rates: 88200, 96000
   Altset 2
     Format: S24_3LE
     Channels: 2
     Endpoint: 6 IN (SYNC)
     Rates: 11025, 22050, 44100, 48000
   Altset 3
     Format: S16_LE
     Channels: 2
     Endpoint: 6 IN (SYNC)
     Rates: 11025, 22050, 44100, 48000

----

> 
> did you run jack with 48k immediately after setting 96k?
> so, some old configuration is left and this makes the difference.
> perhaps this is also the problem once you reported that the driver
> works only after once capture runs.
> 

No it was playback from the internal pcm :) I see the problem though. 
It's because the quattro only supports 96Khz at 24_3Le. So JACK cannot 
access the pcm as there is no support for this bit rate in JACK.

Apart from that the sound quality of playback when running native alsa 
is crisp and clean. It's hard to tell if the pitch is out or not. It 
could be that I'm not used to listening to such high quality signals :)

But when I record a signal through hw:2,0 while playing (full dulplex) 
both signals (i/o - hw:2,0) become distorted. I have a 48Khz wav file 
for you to listen to.

http://www.boosthardware.com/audio/sine-0913.wav

This is probably contributing to the distortion in JACK too. As JACK 
opens both input and output.  I just confirmed that the quality is much 
better when using the Playback only option.

eg.    jackd -v -d alsa -d quattro1 -p 768 -P




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: USB Audio/Midiman - partial success

[Takashi Iwai]

At Thu, 12 Sep 2002 23:19:30 -0700 (PDT),
Fedor G. Pikus <fedorp@wv.mentorg.com> wrote:
> 
> So yeah, S16_LE at 48000 is not there. But in rc3 it is there, and it works!
> So I don't think this is right, I should have -f dat.

could you update the cvs tree again and configure the driver with
--debug=detect option?  this will show which interface/alts are
actually probed.

also, try another controller module, if possible.
this might change the accessible interfaces (as you reported).


Takashi


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