Re: [alsa-devel] Fw: Isochronous transfer error on USB3
Mauro Carvalho Chehab wrote:
I'm getting an weird behavior with em28xx, especially when the device
is connected into an audio port.
http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c
What happens is that, when I require xawtv3 to use any latency lower
than 65 ms, the audio doesn't work, as it gets lots of underruns per
second.
The driver uses five URBs with 64 frames each, so of course it
will not be able to properly handle periods smaller than that.
FYI, em28xx works at a 48000 KHz sampling rate, and its PM capture Hw
is described as:
static struct snd_pcm_hardware snd_em28xx_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_INTERLEAVED|
SNDRV_PCM_INFO_BATCH |
SNDRV_PCM_INFO_MMAP_VALID,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,
This should be just SNDRV_PCM_RATE_48000.
.period_bytes_min = 64, /* 12544/2, */
This is wrong (if the driver doesn't install other constraints on the
period length, like the USB audio class driver does).
Regards,
Clemens
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Fw: Isochronous transfer error on USB3
Em Thu, 09 Jan 2014 09:17:13 +0100
Clemens Ladisch clem...@ladisch.de escreveu:
Mauro Carvalho Chehab wrote:
I'm getting an weird behavior with em28xx, especially when the device
is connected into an audio port.
http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c
What happens is that, when I require xawtv3 to use any latency lower
than 65 ms, the audio doesn't work, as it gets lots of underruns per
second.
The driver uses five URBs with 64 frames each, so of course it
will not be able to properly handle periods smaller than that.
FYI, em28xx works at a 48000 KHz sampling rate, and its PM capture Hw
is described as:
static struct snd_pcm_hardware snd_em28xx_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_INTERLEAVED|
SNDRV_PCM_INFO_BATCH |
SNDRV_PCM_INFO_MMAP_VALID,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,
This should be just SNDRV_PCM_RATE_48000.
Ok.
.period_bytes_min = 64, /* 12544/2, */
This is wrong (if the driver doesn't install other constraints on the
period length, like the USB audio class driver does).
Ok, how should it be estimated? Those values here were simply glued from
the USB audio class driver a long time ago without a further analysis.
I changed it to 188 (the minimum URB size I experimentally noticed with
the current settings) and it is now working fine with both xHCI and EHCI.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Fw: Isochronous transfer error on USB3
Em Thu, 9 Jan 2014 09:29:57 -0200
Mauro Carvalho Chehab m.che...@samsung.com escreveu:
Em Thu, 09 Jan 2014 09:17:13 +0100
Clemens Ladisch clem...@ladisch.de escreveu:
Mauro Carvalho Chehab wrote:
I'm getting an weird behavior with em28xx, especially when the device
is connected into an audio port.
http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c
What happens is that, when I require xawtv3 to use any latency lower
than 65 ms, the audio doesn't work, as it gets lots of underruns per
second.
The driver uses five URBs with 64 frames each, so of course it
will not be able to properly handle periods smaller than that.
FYI, em28xx works at a 48000 KHz sampling rate, and its PM capture Hw
is described as:
static struct snd_pcm_hardware snd_em28xx_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_INTERLEAVED|
SNDRV_PCM_INFO_BATCH |
SNDRV_PCM_INFO_MMAP_VALID,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,
This should be just SNDRV_PCM_RATE_48000.
Ok.
.period_bytes_min = 64, /* 12544/2, */
This is wrong (if the driver doesn't install other constraints on the
period length, like the USB audio class driver does).
Ok, how should it be estimated? Those values here were simply glued from
the USB audio class driver a long time ago without a further analysis.
I changed it to 188 (the minimum URB size I experimentally noticed with
the current settings) and it is now working fine with both xHCI and EHCI.
PS.: using 188 there, the URBs now have a total actual size of 24 bytes.
Regards,
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: Isochronous transfer error on USB3
Hi Hans/Takashi,
I'm getting an weird behavior with em28xx, especially when the device
is connected into an audio port.
I'm using, on my tests, an em28xx HVR-950 device, using this tree:
http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/em28xx-v4l2-v6
Where the alsa driver is at:
http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c
I'm testing it with xawtv3 (http://git.linuxtv.org/xawtv3.git). The
ALSA userspace code there is at:
http://git.linuxtv.org/xawtv3.git/blob/HEAD:/common/alsa_stream.c
What happens is that, when I require xawtv3 to use any latency lower
than 65 ms, the audio doesn't work, as it gets lots of underruns per
second.
FYI, em28xx works at a 48000 KHz sampling rate, and its PM capture Hw
is described as:
static struct snd_pcm_hardware snd_em28xx_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_INTERLEAVED|
SNDRV_PCM_INFO_BATCH |
SNDRV_PCM_INFO_MMAP_VALID,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,
.rate_min = 48000,
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
.buffer_bytes_max = 62720 * 8, /* just about the value in usbaudio.c */
.period_bytes_min = 64, /* 12544/2, */
.period_bytes_max = 12544,
.periods_min = 2,
.periods_max = 98, /* 12544, */
};
On my tests, I experimentally discovered that the minimal latency to
avoid ALSA library underruns is:
- 65ms when using xHCI;
- 25ms when using EHCI.
Any latency lower than that causes lots of overruns. Very high
latency also causes overruns (but on a lower rate, as the period
is bigger).
I'm wandering if is there anything that could be done either at Kernel
side or at userspace side to automatically get some configuration that
works as-is, without requiring the user to play with the latency parameter
by hand.
The alsa-info data is enclosed.
Thank you!
Mauro
PS.: I'm still trying to understand why the minimal allowed latency is
different when using xHCI, but I suspect that it is because it uses a
different urb-interval than EHCI.
Forwarded message:
Date: Wed, 08 Jan 2014 16:03:51 -0200
From: Mauro Carvalho Chehab m.che...@samsung.com
To: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: jean-philippe francois jp.franc...@cynove.com, linux-...@vger.kernel.org,
LMML linux-media@vger.kernel.org, Shuah Khan shuah...@samsung.com
Subject: Re: Isochronous transfer error on USB3
Em Wed, 08 Jan 2014 15:05:12 -0200
Mauro Carvalho Chehab m.che...@samsung.com escreveu:
Em Wed, 08 Jan 2014 14:31:28 -0200
Mauro Carvalho Chehab m.che...@samsung.com escreveu:
Em Thu, 02 Jan 2014 14:07:22 -0800
Sarah Sharp sarah.a.sh...@linux.intel.com escreveu:
On Sun, Dec 29, 2013 at 02:54:40AM -0200, Mauro Carvalho Chehab wrote:
It seems that usb_unlink_urb() is causing troubles with xHCI: the
endpoint stops streaming, but, after that, it doesn't start again,
and lots of debug messages are produced. I emailed you the full log
after start streaming in priv (too big for vger), but basically,
it produces:
[ 1635.754546] xhci_hcd :00:14.0: Endpoint 0x81 not halted,
refusing to reset.
[ 1635.754562] xhci_hcd :00:14.0: Endpoint 0x82 not halted,
refusing to reset.
[ 1635.754577] xhci_hcd :00:14.0: Endpoint 0x83 not halted,
refusing to reset.
[ 1635.754594] xhci_hcd :00:14.0: Endpoint 0x84 not halted,
refusing to reset.
I think that's due to the driver (or userspace) attempting to reset the
endpoint when it didn't actually receive a stall (-EPIPE) status from an
URB. When that happens, the xHCI host controller endpoint toggle bits
get out of sync with the device toggle bits, and the result is that all
transfers will fail to the endpoint from then on until you switch
alternate interface settings or unplug/replug the device.
Try this patch:
http://marc.info/?l=linux-usbm=138116117104619w=2
It's still under RFC, and I know it has race conditions, but it will let
you quickly test whether this fixes your issue.
Didn't work fine, or at least it didn't solve all the problems. Also, it
started to cause OOPSes due to the race conditions.
This has been a long-standing xHCI driver bug. I asked my OPW intern to
work on the patch to fix it, but she may be a bit busy with her new job
to finish up the RFC. I'll probably have to take over finishing the
patch, if this turns out to be your issue.
(Not sure why it is trying to stop all endpoints - as just one endpoint
was
requested to restart).
Something is calling into usb_clear_halt() with all the endpoints.
Re: Fw: Isochronous transfer error on USB3
On Wed, 8 Jan 2014, Mauro Carvalho Chehab wrote:
Hi Hans/Takashi,
I'm getting an weird behavior with em28xx, especially when the device
is connected into an audio port.
I'm using, on my tests, an em28xx HVR-950 device, using this tree:
http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/em28xx-v4l2-v6
Where the alsa driver is at:
http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/em28xx-v4l2-v6:/drivers/media/usb/em28xx/em28xx-audio.c
I'm testing it with xawtv3 (http://git.linuxtv.org/xawtv3.git). The
ALSA userspace code there is at:
http://git.linuxtv.org/xawtv3.git/blob/HEAD:/common/alsa_stream.c
What happens is that, when I require xawtv3 to use any latency lower
than 65 ms, the audio doesn't work, as it gets lots of underruns per
second.
FYI, em28xx works at a 48000 KHz sampling rate, and its PM capture Hw
is described as:
static struct snd_pcm_hardware snd_em28xx_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_INTERLEAVED|
SNDRV_PCM_INFO_BATCH |
SNDRV_PCM_INFO_MMAP_VALID,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,
.rate_min = 48000,
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
.buffer_bytes_max = 62720 * 8, /* just about the value in usbaudio.c */
.period_bytes_min = 64, /* 12544/2, */
.period_bytes_max = 12544,
.periods_min = 2,
.periods_max = 98, /* 12544, */
};
On my tests, I experimentally discovered that the minimal latency to
avoid ALSA library underruns is:
- 65ms when using xHCI;
- 25ms when using EHCI.
Any latency lower than that causes lots of overruns. Very high
latency also causes overruns (but on a lower rate, as the period
is bigger).
I'm wandering if is there anything that could be done either at Kernel
side or at userspace side to automatically get some configuration that
works as-is, without requiring the user to play with the latency parameter
by hand.
The alsa-info data is enclosed.
Thank you!
Mauro
PS.: I'm still trying to understand why the minimal allowed latency is
different when using xHCI, but I suspect that it is because it uses a
different urb-interval than EHCI.
You may be able to answer some of these questions by collecting usbmon
traces (see Documentation/usb/usbmon.txt). That would help pinpoint
sources of latency and tell you the actual URB intervals.
25 ms to avoid underruns seems pretty large. Other people, using audio
only (no video), find that EHCI can work well with latencies as low as
2 ms or so. (That's using 3.13-rc, which includes some changes in the
snd-usb-audio driver.)
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
