mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* snd_usb_audio
@ 2005-11-15 23:18 Markus Rechberger
  2005-11-16  9:11 ` snd_usb_audio Clemens Ladisch
  0 siblings, 1 reply; 3+ messages in thread
From: Markus Rechberger @ 2005-11-15 23:18 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: snd_usb_audio
  2005-11-15 23:18 snd_usb_audio Markus Rechberger
@ 2005-11-16  9:11 ` Clemens Ladisch
  2005-11-16 11:07   ` snd_usb_audio Markus Rechberger
  0 siblings, 1 reply; 3+ messages in thread
From: Clemens Ladisch @ 2005-11-16  9:11 UTC (permalink / raw)
  To: Markus Rechberger; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: snd_usb_audio
  2005-11-16  9:11 ` snd_usb_audio Clemens Ladisch
@ 2005-11-16 11:07   ` Markus Rechberger
  0 siblings, 0 replies; 3+ messages in thread
From: Markus Rechberger @ 2005-11-16 11:07 UTC (permalink / raw)
  To: Clemens Ladisch; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-11-16 11:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-15 23:18 snd_usb_audio Markus Rechberger
2005-11-16  9:11 ` snd_usb_audio Clemens Ladisch
2005-11-16 11:07   ` snd_usb_audio Markus Rechberger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®