Re: snd_usb_audio

[Markus Rechberger <mrechberger@gmail.com>]

On 11/16/05, Clemens Ladisch <clemens@ladisch.de> wrote:
> Markus Rechberger wrote:
> > finally the em28xx driver made it into the kerneltree, but one
> > problem still remains
> > the snd_usb_audio driver.
> >
> > The problem with the snd_usb_audio driver is that it only supports
> > up to 10 isochronous packets.
>
> This is packets per URB; we typically have 8 URBs.
>
> > If people watch TV using such a framegrabber device and set audio
> > to > 8000hz the video isoc transfer will break and the video will
> > stop.
>
> What exactly breaks?  Are you using playback or capture?
>

the video isoc transfer screws up, finally it even stops. submitting
the video isoc urbs starts to fail.

> If there is an underrun when starting a _playback_ stream, then it's a
> known bug that has been fixed in 2.6.15-rc1.
>

it's playback, I'll test the release canditate tonight hopefully it's solved.

> > regarding usbaudio.c (in 2.6.14):
> > #define MAX_PACKS       10
> > #define MAX_PACKS_HS    (MAX_PACKS * 8) /* in high speed mode */
> >
> > MAX_PACKS is the upper limit that is adjustable, the second one
> > isn't used at all
> >
> > an easy hack would be to allow up to 100 packets but I also have a
> > usb 1.1 soundblaster that might have problems with too many packets.
> >
> > The correct value for em28xx devices is around 80 packets.
>
> Did you test this?  Capturing doesn't use MAX_PACKS.
>

yes I tested this regarding the sniffed windows logfile 80 would
probably the best value for it, the stream didn't break with that
value actually. as I already wrote it's playback.

> > does anyone know more about the packet limitations on USB 1.1 and
> > 2.0 devices?
>
> The only limitation are the host controller drivers.
>
ok thanks so far!

Markus