Hi,
finally the em28xx driver made it into the kerneltree, but one problem
still remains
the snd_usb_audio driver.
the em28xx driver various framegrabber devices (pinnacle, hauppauge,
terratec,..).
The problem with the snd_usb_audio driver is that it only supports up
to 10 isochronous packets. 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.
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.
does anyone know more about the packet limitations on USB 1.1 and 2.0 devices?
MAX_PACKS_HS isn't used anywhere, but defined as MAX_PACKS * 8. I
don't know if it's just safe to say MAX_PACKS * 8 would fit for high
speed devices.
Unless this bug isn't fixed the em28xx driver is quite useless in the
kerneltree since it will not work with digital usb audio
Markus
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?
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.
> 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.
> does anyone know more about the packet limitations on USB 1.1 and
> 2.0 devices?
The only limitation are the host controller drivers.
HTH
Clemens
On 11/16/05, Clemens Ladisch <[email protected]> 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