* 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®