* [PATCH 0/3] Auvitek au0828 fixups
@ 2014-06-14 16:16 Mauro Carvalho Chehab
2014-06-14 16:16 ` [PATCH 1/3] sound: Add a quirk to enforce period_bytes Mauro Carvalho Chehab
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Mauro Carvalho Chehab @ 2014-06-14 16:16 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab
Testing auvitek au0828-based devices with xawtv caused lots of overruns,
as the period_bytes is set to a too low value, with causes troubles
when syncing the audio capture from au0828 card with the audio playback,
at the main audio card.
It turns that we need a period_bytes size that it is big enough to receive
data from two consecutive URB intervals.
While here, also add the missing USB IDs from other au0828-based devices.
Mauro Carvalho Chehab (3):
sound: Add a quirk to enforce period_bytes
sound: simplify au0828 quirk table
sound: Update au0828 quirks table
sound/usb/card.h | 1 +
sound/usb/pcm.c | 34 ++++++++++
sound/usb/quirks-table.h | 167 ++++++++++++-----------------------------------
sound/usb/quirks.c | 14 ++--
sound/usb/stream.c | 1 +
sound/usb/usbaudio.h | 3 +-
6 files changed, 88 insertions(+), 132 deletions(-)
--
1.9.3
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-14 16:16 [PATCH 0/3] Auvitek au0828 fixups Mauro Carvalho Chehab @ 2014-06-14 16:16 ` Mauro Carvalho Chehab 2014-06-16 7:39 ` [alsa-devel] " Clemens Ladisch 2014-06-14 16:16 ` [PATCH 2/3] sound: simplify au0828 quirk table Mauro Carvalho Chehab 2014-06-14 16:16 ` [PATCH 3/3] sound: Update au0828 quirks table Mauro Carvalho Chehab 2 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-14 16:16 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List, Mauro Carvalho Chehab, stable The Auvitek 0828 chip, used on HVR950Q actually need two quirks and not just one. The first one, already implemented, enforces that it won't have channel swaps at the transfers. However, for TV applications, like xawtv and tvtime, another quirk is needed, in order to enforce that, at least 2 URB transfer intervals will be needed to fill a buffer. Without it, buffer underruns happen when trying to syncronize the audio input from au0828 and the audio playback at the default audio output device. As the second quirk may be needed by some other media devices not based on au0828 chipset, keep it as a separate quirk. Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> --- sound/usb/card.h | 1 + sound/usb/pcm.c | 34 ++++++++++++++++++++++++++++++++++ sound/usb/quirks-table.h | 18 +++++++++--------- sound/usb/quirks.c | 14 ++++++++++---- sound/usb/stream.c | 1 + sound/usb/usbaudio.h | 3 ++- 6 files changed, 57 insertions(+), 14 deletions(-) diff --git a/sound/usb/card.h b/sound/usb/card.h index 97acb906acc2..f6f2c7ca6ed4 100644 --- a/sound/usb/card.h +++ b/sound/usb/card.h @@ -122,6 +122,7 @@ struct snd_usb_substream { unsigned int buffer_periods; /* current periods per buffer */ unsigned int altset_idx; /* USB data format: index of alternate setting */ unsigned int txfr_quirk:1; /* allow sub-frame alignment */ + unsigned int media_sync_quirk:1;/* Enforce a min period_bytes big enough to handle 2 URB transfer periods */ unsigned int fmt_type; /* USB audio format type (1-3) */ unsigned int pkt_offset_adj; /* Bytes to drop from beginning of packets (for non-compliant devices) */ diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index c62a1659106d..e4a215b63d9f 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1102,6 +1102,8 @@ static int setup_hw_info(struct snd_pcm_runtime *runtime, struct snd_usb_substre unsigned int pt, ptmin; int param_period_time_if_needed; int err; + size_t period_bytes_min = UINT_MAX; + size_t period_bytes_max = 0; runtime->hw.formats = subs->formats; @@ -1129,7 +1131,39 @@ static int setup_hw_info(struct snd_pcm_runtime *runtime, struct snd_usb_substre } pt = 125 * (1 << fp->datainterval); ptmin = min(ptmin, pt); + + if (subs->media_sync_quirk) { + size_t period, min_period, max_period; + + /* + * multimedia streams have both Audio and Video + * URBs and limited contraints with regards to + * the period size. Also, their stream will be + * most likely synked with the playback card with + * different constraints. + * Due to that, we need to be sure that, at least + * 2 URB transfers will be needed to fill a period, + * in order to avoid buffer underruns on applications + * like tvtime and xawtv. + * A non-multiple of period_bytes_min can also be + * a problem, so the best is to also enfoce it. + */ + period = 2 * MAX_URBS * fp->maxpacksize; + min_period = period * 90 / 100; + max_period = period * 110 / 100; + + if (period_bytes_min > min_period) + period_bytes_min = min_period; + if (period_bytes_max < max_period) + period_bytes_max = max_period; + } } + + if (period_bytes_min != UINT_MAX && period_bytes_max != 0) { + runtime->hw.period_bytes_min = period_bytes_min; + runtime->hw.period_bytes_max = period_bytes_max; + } + err = snd_usb_autoresume(subs->stream->chip); if (err < 0) return err; diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index f652b10ce905..236adf61d27a 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2757,7 +2757,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2771,7 +2771,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2785,7 +2785,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2799,7 +2799,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2813,7 +2813,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2827,7 +2827,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2841,7 +2841,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-850", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2855,7 +2855,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, { @@ -2869,7 +2869,7 @@ YAMAHA_DEVICE(0x7010, "UB99"), .vendor_name = "Hauppauge", .product_name = "HVR-950Q", .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_ALIGN_TRANSFER, + .type = QUIRK_AUDIO_AUVITEK_0828, } }, diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index 7c57f2268dd7..fea68eef5bdb 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -74,15 +74,21 @@ static int ignore_interface_quirk(struct snd_usb_audio *chip, /* - * Allow alignment on audio sub-slot (channel samples) rather than - * on audio slots (audio frames) + * There are actually two quirks needed by Auvitek 0828 audio: + * + * 1) Allow alignment on audio sub-slot (channel samples) rather than + * on audio slots (audio frames), enabled via chip->txfr_quirk + * + * 2) Enforce that the minimum period_bytes will be able to store, + * at least, 2 URB transfer intervals. */ -static int create_align_transfer_quirk(struct snd_usb_audio *chip, +static int create_auvitek_0828_quirk(struct snd_usb_audio *chip, struct usb_interface *iface, struct usb_driver *driver, const struct snd_usb_audio_quirk *quirk) { chip->txfr_quirk = 1; + chip->media_sync_quirk = 1; return 1; /* Continue with creating streams and mixer */ } @@ -529,7 +535,7 @@ int snd_usb_create_quirk(struct snd_usb_audio *chip, [QUIRK_AUDIO_STANDARD_INTERFACE] = create_standard_audio_quirk, [QUIRK_AUDIO_FIXED_ENDPOINT] = create_fixed_stream_quirk, [QUIRK_AUDIO_EDIROL_UAXX] = create_uaxx_quirk, - [QUIRK_AUDIO_ALIGN_TRANSFER] = create_align_transfer_quirk, + [QUIRK_AUDIO_AUVITEK_0828] = create_auvitek_0828_quirk, [QUIRK_AUDIO_STANDARD_MIXER] = create_standard_mixer_quirk, }; diff --git a/sound/usb/stream.c b/sound/usb/stream.c index 310a3822d2b7..2ea6516e5e34 100644 --- a/sound/usb/stream.c +++ b/sound/usb/stream.c @@ -92,6 +92,7 @@ static void snd_usb_init_substream(struct snd_usb_stream *as, subs->direction = stream; subs->dev = as->chip->dev; subs->txfr_quirk = as->chip->txfr_quirk; + subs->media_sync_quirk = as->chip->media_sync_quirk; subs->speed = snd_usb_get_speed(subs->dev); subs->pkt_offset_adj = 0; diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h index 91d0380431b4..a38e94554022 100644 --- a/sound/usb/usbaudio.h +++ b/sound/usb/usbaudio.h @@ -43,6 +43,7 @@ struct snd_usb_audio { unsigned int in_pm:1; unsigned int autosuspended:1; unsigned int txfr_quirk:1; /* Subframe boundaries on transfers */ + unsigned int media_sync_quirk:1;/* Enforce a min period_bytes big enough to handle 2 URB transfer periods */ int num_interfaces; int num_suspended_intf; @@ -97,7 +98,7 @@ enum quirk_type { QUIRK_AUDIO_STANDARD_INTERFACE, QUIRK_AUDIO_FIXED_ENDPOINT, QUIRK_AUDIO_EDIROL_UAXX, - QUIRK_AUDIO_ALIGN_TRANSFER, + QUIRK_AUDIO_AUVITEK_0828, QUIRK_AUDIO_STANDARD_MIXER, QUIRK_TYPE_COUNT -- 1.9.3 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-14 16:16 ` [PATCH 1/3] sound: Add a quirk to enforce period_bytes Mauro Carvalho Chehab @ 2014-06-16 7:39 ` Clemens Ladisch 2014-06-16 13:22 ` Devin Heitmueller 2014-06-16 14:21 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 16+ messages in thread From: Clemens Ladisch @ 2014-06-16 7:39 UTC (permalink / raw) To: Mauro Carvalho Chehab, Takashi Iwai Cc: alsa-devel, Linux Media Mailing List, Mauro Carvalho Chehab (CC stable dropped; this is not how to submit stable patches.) Mauro Carvalho Chehab wrote: > The Auvitek 0828 chip, used on HVR950Q actually need two > quirks and not just one. > > The first one, already implemented, enforces that it won't have > channel swaps at the transfers. > > However, for TV applications, like xawtv and tvtime, another quirk > is needed, in order to enforce that, at least 2 URB transfer > intervals will be needed to fill a buffer. > + period = 2 * MAX_URBS * fp->maxpacksize; > + min_period = period * 90 / 100; > + max_period = period * 110 / 100; I don't quite understand what you mean with "URB transfer interval". All USB audio devices transfer packets in intervals between 125 µs and 1000 µs. MAX_URBS is a somewhat random value that is not directly derived from either a hardware or software constraint. Are you trying to enforce two packets per URB? Why are you setting both a minimum and a maximum? Isn't this affected by the constraints of the playback device? > Without it, buffer underruns happen when trying to syncronize the > audio input from au0828 and the audio playback at the default audio > output device. This looks like a workaround for a userspace bug that would affect all USB audio devices. What period/buffer sizes are xawtv/tvtime trying to use? Regards, Clemens ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 7:39 ` [alsa-devel] " Clemens Ladisch @ 2014-06-16 13:22 ` Devin Heitmueller 2014-06-16 15:05 ` [alsa-devel] " Mauro Carvalho Chehab 2014-06-16 14:21 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 16+ messages in thread From: Devin Heitmueller @ 2014-06-16 13:22 UTC (permalink / raw) To: Clemens Ladisch Cc: Takashi Iwai, alsa-devel, Linux Media Mailing List, Mauro Carvalho Chehab, Mauro Carvalho Chehab > This looks like a workaround for a userspace bug that would affect all > USB audio devices. What period/buffer sizes are xawtv/tvtime trying to > use? I have similar concerns, although I don't know what the right solution is. For example, the last time Mauro tweaked the latency in tvtime, it broke support for all cx231xx devices (note that tvtime and xawtv share essentially the same ALSA code): http://git.linuxtv.org/cgit.cgi/tvtime.git/commit/?id=3d58ba563bfcc350c180b59a94cec746ccad6ebe It seems like there is definitely something wrong with the latency/period selection in both applications, but we need some insight from people who are better familiar with the ALSA subsystem for advice on the "right" way to do low latency audio capture (i.e. properly negotiating minimal latency in a way that works with all devices). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 13:22 ` Devin Heitmueller @ 2014-06-16 15:05 ` Mauro Carvalho Chehab 2014-06-18 8:20 ` Clemens Ladisch 0 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-16 15:05 UTC (permalink / raw) To: Devin Heitmueller Cc: Clemens Ladisch, Takashi Iwai, alsa-devel, Linux Media Mailing List, Mauro Carvalho Chehab Em Mon, 16 Jun 2014 09:22:08 -0400 Devin Heitmueller <dheitmueller@kernellabs.com> escreveu: > > This looks like a workaround for a userspace bug that would affect all > > USB audio devices. What period/buffer sizes are xawtv/tvtime trying to > > use? > > I have similar concerns, although I don't know what the right solution > is. For example, the last time Mauro tweaked the latency in tvtime, > it broke support for all cx231xx devices (note that tvtime and xawtv > share essentially the same ALSA code): > > http://git.linuxtv.org/cgit.cgi/tvtime.git/commit/?id=3d58ba563bfcc350c180b59a94cec746ccad6ebe > > It seems like there is definitely something wrong with the > latency/period selection in both applications, but we need some > insight from people who are better familiar with the ALSA subsystem > for advice on the "right" way to do low latency audio capture (i.e. > properly negotiating minimal latency in a way that works with all > devices). Well, I suspect that the issue is at Kernel level. Let's see the au0828 case: 48 kHz, 2 bytes/sample, 2 channels, 256 maxpacksize, 1 ms URB interval (bInterval = 1). In this case, there is 192 bytes per 1ms period. Let's assume that the period was set to 3456, with corresponds to a latency of 18 ms. In this case, as NUM_URBS = 12, it means that the transfer buffer will be set to its maximum value of 3072 bytes per URB pack (12 * 256), and the URB transfer_callback will be called on every 16 ms. So, what happens is: - after 16 ms, the first 3072 bytes arrive. The next packet will take another 16ms to arrive; - after 2 ms, underrun, as the period_size was not filled yet. The thing is that any latency that between 16 ms and 32 ms are invalid, as the URB settings won't support it. Regards, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 15:05 ` [alsa-devel] " Mauro Carvalho Chehab @ 2014-06-18 8:20 ` Clemens Ladisch 0 siblings, 0 replies; 16+ messages in thread From: Clemens Ladisch @ 2014-06-18 8:20 UTC (permalink / raw) To: Mauro Carvalho Chehab, Devin Heitmueller Cc: Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List Mauro Carvalho Chehab wrote: > Let's see the au0828 case: > 48 kHz, 2 bytes/sample, 2 channels, 256 maxpacksize, 1 ms URB > interval (bInterval = 1). > > In this case, there is 192 bytes per 1ms period. The device's clock and the bus clock are not synchronized, so there will be _approximately_ 192 bytes per USB frame. > Let's assume that the period was set to 3456, with corresponds to > a latency of 18 ms. > > In this case, as NUM_URBS = 12, There is no symbol named NUM_URBS. > it means that the transfer buffer will be set to its maximum value of > 3072 bytes per URB pack (12 * 256) The number of URBs is not the same as the number of packets per URB. > and the URB transfer_callback will be called on every 16 ms. It will be called once per millisecond. > So, what ... definitely not ... > happens is: > > - after 16 ms, the first 3072 bytes arrive. The next > packet will take another 16ms to arrive; > - after 2 ms, underrun, as the period_size was not > filled yet. Regards, Clemens ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 7:39 ` [alsa-devel] " Clemens Ladisch 2014-06-16 13:22 ` Devin Heitmueller @ 2014-06-16 14:21 ` Mauro Carvalho Chehab 2014-06-16 14:38 ` Alexander E. Patrakov 2014-06-18 8:21 ` Clemens Ladisch 1 sibling, 2 replies; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-16 14:21 UTC (permalink / raw) To: Clemens Ladisch Cc: Takashi Iwai, alsa-devel, Linux Media Mailing List, Mauro Carvalho Chehab Em Mon, 16 Jun 2014 09:39:17 +0200 Clemens Ladisch <clemens@ladisch.de> escreveu: > (CC stable dropped; this is not how to submit stable patches.) > > Mauro Carvalho Chehab wrote: > > The Auvitek 0828 chip, used on HVR950Q actually need two > > quirks and not just one. > > > > The first one, already implemented, enforces that it won't have > > channel swaps at the transfers. > > > > However, for TV applications, like xawtv and tvtime, another quirk > > is needed, in order to enforce that, at least 2 URB transfer > > intervals will be needed to fill a buffer. > > > + period = 2 * MAX_URBS * fp->maxpacksize; > > + min_period = period * 90 / 100; > > + max_period = period * 110 / 100; > > I don't quite understand what you mean with "URB transfer interval". > > All USB audio devices transfer packets in intervals between 125 µs and > 1000 µs. In this case, it uses a 1000 µs, as defined at the USB descriptor for the au0828 devices (bInterval). FYI, those TV devices are too limited, in terms of audio: they only provide: - 48 kHz rate; - 16 bits/sample; - 2 channels; - maxumum URB size: 256 bytes. Its internal firmware is also too buggy. We needed to add several workarounds at both analog and digital stream support for some conditions that caused the chip to stop producing URBs, or made it to cause ESHUTDOWN errors while streaming. > MAX_URBS is a somewhat random value that is not directly derived from > either a hardware or software constraint. Yes, I noticed that. > Are you trying to enforce two packets per URB? No, I'm trying to enforce that it won't complain about underruns, while keeping the latency constrained. This is the same kind of fix we needed to do with em28xx-audio.c some time ago. In this case, I'm enforcing that the URB callback will receive 3072 samples, and that the PCM timer won't be triggered too early, e. g. it will wait for the needed time for the URB callback to be called twice. > Why are you setting both a minimum and a maximum? When I wrote em28xx patches, I did several tests with different max latency constraints. On some cases, when it selected an odd number of periods, we would still have some troubles. So, it sounds safer to keep the same type of logic here. Anyway, just setting the minimum is enough for xawtv/tvtime to work with the default -alsa-latency parameter. > Isn't this affected by the constraints of the playback device? Hard to tell without having a test hardware with different constraints. All playback hardware I currently have supports 48 kHz rate, and supports a period size in the range of this The application takes those constraints into account > > > Without it, buffer underruns happen when trying to syncronize the > > audio input from au0828 and the audio playback at the default audio > > output device. > > This looks like a workaround for a userspace bug that would affect all > USB audio devices. What period/buffer sizes are xawtv/tvtime trying to > use? Both xawtv and tvtime use the same code for audio: http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c There's an algorithm there that gets the period size form both the capture and the playback cards, trying to find a minimum period that would work properly for both. It tries to enforce a choice where the max latency would be constrained. The max latency is 30ms, by default, but the user can change it via -alsa-latency parameter. Regards, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 14:21 ` Mauro Carvalho Chehab @ 2014-06-16 14:38 ` Alexander E. Patrakov 2014-06-16 16:24 ` Mauro Carvalho Chehab 2014-06-18 8:21 ` Clemens Ladisch 1 sibling, 1 reply; 16+ messages in thread From: Alexander E. Patrakov @ 2014-06-16 14:38 UTC (permalink / raw) To: Mauro Carvalho Chehab, Clemens Ladisch Cc: Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List 16.06.2014 20:21, Mauro Carvalho Chehab wrote: > Both xawtv and tvtime use the same code for audio: > http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c > > There's an algorithm there that gets the period size form both the > capture and the playback cards, trying to find a minimum period that > would work properly for both. I don't see any adaptive resampler (similar to what module-loopback does in pulseaudio) there. Without that, or dynamically controlling the audio capture clock PLL in the tuner, xruns are unavoidable when transferring data between two unrelated cards. So, until any further evidence appears, I think it is a common bug in these audio codes. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 14:38 ` Alexander E. Patrakov @ 2014-06-16 16:24 ` Mauro Carvalho Chehab 2014-06-16 17:16 ` Alexander E. Patrakov 0 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-16 16:24 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Clemens Ladisch, Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List [-- Attachment #1: Type: text/plain, Size: 1643 bytes --] Em Mon, 16 Jun 2014 20:38:52 +0600 "Alexander E. Patrakov" <patrakov@gmail.com> escreveu: > 16.06.2014 20:21, Mauro Carvalho Chehab wrote: > > Both xawtv and tvtime use the same code for audio: > > http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c > > > > There's an algorithm there that gets the period size form both the > > capture and the playback cards, trying to find a minimum period that > > would work properly for both. > > I don't see any adaptive resampler (similar to what module-loopback does > in pulseaudio) there. Are you referring to changing the sample rate? This doesn't affect my test scenario, as the playback interface supports the only PCM format/rate used by the TV card (48kHz, 16 bits/sample, stereo): Codec: Realtek ALC269VC Default PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM > Without that, or dynamically controlling the audio > capture clock PLL in the tuner, xruns are unavoidable when transferring > data between two unrelated cards. What do you mean by dynamically controlling the audio capture clock PLL in the tuner? That doesn't make any sense to me. The xc5000 tuner used on this TV device doesn't provide any mechanism to control audio PLL. It just sends the audio samples to au0828 via a I2S bus. All the audio control is done by the USB bridge at au0828, and that is pretty much limited. The only control that au0828 accepts is the control of the URB buffers (e. g., number of URB packets and URB size). > > So, until any further evidence appears, I think it is a common bug in > these audio codes. > [-- Attachment #2: alsa-info.txt.7qy7T0g90U --] [-- Type: application/octet-stream, Size: 33796 bytes --] upload=true&script=true&cardinfo= !!################################ !!ALSA Information Script v 0.4.62 !!################################ !!Script ran on: Mon Jun 16 16:11:59 UTC 2014 !!Linux Distribution !!------------------ Fedora release 20 (Heisenbug) Fedora release 20 (Heisenbug) NAME=Fedora ID=fedora PRETTY_NAME="Fedora 20 (Heisenbug)" CPE_NAME="cpe:/o:fedoraproject:fedora:20" HOME_URL="https://fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=20 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=20 Fedora release 20 (Heisenbug) Fedora release 20 (Heisenbug) !!DMI Information !!--------------- Manufacturer: SAMSUNG ELECTRONICS CO., LTD. Product Name: 550P5C/550P7C Product Version: P05ABI Firmware Version: P05ABI.016.130917.dg !!Kernel Information !!------------------ Kernel release: 3.15.0+ Operating System: GNU/Linux Architecture: x86_64 Processor: x86_64 SMP Enabled: Yes !!ALSA Version !!------------ Driver version: k3.15.0+ Library version: 1.0.27.2 Utilities version: 1.0.27.2 !!Loaded ALSA modules !!------------------- snd_hda_intel snd_usb_audio !!Sound Servers on this system !!---------------------------- Pulseaudio: Installed - Yes (/bin/pulseaudio) Running - Yes Jack: Installed - Yes (/bin/jackd) Running - No !!Soundcards recognised by ALSA !!----------------------------- 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7910000 irq 46 1 [HVR950Q ]: USB-Audio - HVR-950Q Hauppauge HVR-950Q at usb-0000:00:1a.0-1.2.4, high speed !!PCI Soundcards installed in the system !!-------------------------------------- 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) !!Advanced information - PCI Vendor/Device/Subsystem ID's !!------------------------------------------------------- 00:1b.0 0403: 8086:1e20 (rev 04) Subsystem: 144d:c0d1 !!Loaded sound module options !!--------------------------- !!Module: snd_hda_intel align_buffer_size : -1 bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 jackpoll_ms : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 power_save : 0 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 single_cmd : N snoop : Y !!Module: snd_usb_audio autoclock : Y device_setup : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) ignore_ctl_error : N index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 pid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 vid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 !!HDA-Intel Codec information !!--------------------------- --startcollapse-- Codec: Realtek ALC269VC Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0269 Subsystem Id: 0x144dc0d1 Revision Id: 0x100202 No Modem Function Group found Default PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D1 D2 D3 CLKSTOP EPSS Power: setting=D0, actual=D0 GPIO: io=2, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x27 0x27] Converter: stream=5, channel=0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC269VC Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=5, channel=0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x04 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x06 [Audio Output] wcaps 0x611: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x07 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="ALC269VC Analog", type="Audio", device=0 Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1 Amp-In vals: [0x27 0x27] Converter: stream=1, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x23 Node 0x09 [Audio Input] wcaps 0x10051b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1 Amp-In vals: [0x97 0x97] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x22 Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Internal Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Internal Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x02 0x0b Node 0x0d [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x03 0x0b Node 0x0e [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0f [Audio Mixer] wcaps 0x20010a: Mono Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00] [0x00] Connection: 2 0x02 0x0b Node 0x10 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x12 [Pin Complex] wcaps 0x40040b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00010014: OUT EAPD Detect EAPD 0x2: EAPD Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Node 0x15 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x0321101f: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c 0x0d* Node 0x16 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x17 [Pin Complex] wcaps 0x40050c: Mono Amp-Out Control: name="Bass Speaker Playback Switch", index=0, device=0 ControlAmp: chs=1, dir=Out, idx=0, ofs=0 Control: name="Speaker Surround Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00] Pincap 0x00000010: OUT Pin Default 0x90170120: [Fixed] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x2, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x0f Node 0x18 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00003734: IN OUT Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x03a11830: [Jack] Mic at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=02, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Node 0x19 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Internal Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Internal Mic Phantom Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00003734: IN OUT Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x90a70940: [Fixed] Mic at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x4, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Node 0x1a [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Front Phantom Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00003734: IN OUT Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x90170110: [Fixed] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Node 0x1c [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x1d [Pin Complex] wcaps 0x400400: Mono Pincap 0x00000020: IN Pin Default 0x4006a21d: [N/A] Line Out at Ext N/A Conn = Digital, Color = UNKNOWN DefAssociation = 0x1, Sequence = 0xd Pin-ctls: 0x20: IN Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x1e [Pin Complex] wcaps 0x400781: Stereo Digital Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x06 Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono Processing caps: benign=0, ncoeff=37 Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 7 0x18 0x19 0x1a 0x1b 0x1d 0x0b 0x12 Node 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 6 0x18 0x19 0x1a 0x1b 0x1d 0x0b Codec: Intel PantherPoint HDMI Address: 3 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x80862806 Subsystem Id: 0x80860101 Revision Id: 0x100000 No Modem Function Group found Default PCM: rates [0x0]: bits [0x0]: formats [0x0]: Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 CLKSTOP EPSS Power: setting=D0, actual=D0, Clock-stop-OK GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x6611: 8-Channels Digital Converter: stream=0, channel=0 Digital: Enabled GenLevel Digital category: 0x2 IEC Coding Type: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x5]: PCM AC3 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x6611: 8-Channels Digital Converter: stream=0, channel=0 Digital: Enabled Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x5]: PCM AC3 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Node 0x04 [Audio Output] wcaps 0x6611: 8-Channels Digital Converter: stream=0, channel=0 Digital: Enabled Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x5]: PCM AC3 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Node 0x05 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0 Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="ELD", index=0, device=3 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x02 Node 0x06 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x80] Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x58560020: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x03 Node 0x07 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x80] Pincap 0x09000094: OUT Detect HBR HDMI DP Pin Default 0x58560030: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x04 Node 0x08 [Vendor Defined Widget] wcaps 0xf00000: Mono --endcollapse-- !!USB Mixer information !!--------------------- --startcollapse-- USB Mixer: usb_id=0x20407200, ctrlif=1, ctlerr=0 Card: Hauppauge HVR-950Q at usb-0000:00:1a.0-1.2.4, high speed Unit: 3 Control: name="Digital In Capture Switch", index=0 Info: id=3, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN" Volume: min=0, max=1, dBmin=0, dBmax=0 --endcollapse-- !!ALSA Device nodes !!----------------- crw-rw----+ 1 root audio 116, 2 Jun 16 10:19 /dev/snd/controlC0 crw-rw----+ 1 root audio 116, 8 Jun 16 10:19 /dev/snd/controlC1 crw-rw----+ 1 root audio 116, 6 Jun 16 10:19 /dev/snd/hwC0D0 crw-rw----+ 1 root audio 116, 7 Jun 16 10:19 /dev/snd/hwC0D3 crw-rw----+ 1 root audio 116, 4 Jun 16 10:56 /dev/snd/pcmC0D0c crw-rw----+ 1 root audio 116, 3 Jun 16 10:57 /dev/snd/pcmC0D0p crw-rw----+ 1 root audio 116, 5 Jun 16 10:56 /dev/snd/pcmC0D3p crw-rw----+ 1 root audio 116, 9 Jun 16 10:57 /dev/snd/pcmC1D0c crw-rw----+ 1 root audio 116, 1 Jun 16 10:19 /dev/snd/seq crw-rw----+ 1 root audio 116, 33 Jun 16 10:19 /dev/snd/timer /dev/snd/by-id: total 0 drwxr-xr-x. 2 root root 60 Jun 16 10:19 . drwxr-xr-x. 4 root root 280 Jun 16 10:19 .. lrwxrwxrwx. 1 root root 12 Jun 16 10:19 usb-Hauppauge_WinTV_HVR-950_4035199481-01 -> ../controlC1 /dev/snd/by-path: total 0 drwxr-xr-x. 2 root root 80 Jun 16 10:19 . drwxr-xr-x. 4 root root 280 Jun 16 10:19 .. lrwxrwxrwx. 1 root root 12 Jun 16 10:19 pci-0000:00:1a.0-usb-0:1.2.4:1.1 -> ../controlC1 lrwxrwxrwx. 1 root root 12 Jun 16 10:19 pci-0000:00:1b.0 -> ../controlC0 !!ALSA configuration files !!------------------------ !!System wide config file (/etc/asound.conf) # # Place your global alsa-lib configuration here... # !!Aplay/Arecord output !!-------------------- APLAY **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC269VC Analog [ALC269VC Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 ARECORD **** List of CAPTURE Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC269VC Analog [ALC269VC Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HVR950Q [HVR-950Q], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 !!Amixer output !!------------- !!-------Mixer controls for card 0 [PCH] Card hw:0 'PCH'/'HDA Intel PCH at 0xf7910000 irq 46' Mixer name : 'Intel PantherPoint HDMI' Components : 'HDA:10ec0269,144dc0d1,00100202 HDA:80862806,80860101,00100000' Controls : 31 Simple ctrls : 12 Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 87 Mono: Playback 39 [45%] [-36.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 0 [0%] [-65.25dB] [off] Front Right: Playback 0 [0%] [-65.25dB] [off] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 87 [100%] [0.00dB] [on] Front Right: Playback 87 [100%] [0.00dB] [on] Simple mixer control 'Bass Speaker',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [0.00dB] Front Right: Playback 255 [100%] [0.00dB] Simple mixer control 'Mic',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Mic Boost',0 Capabilities: volume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 39 [62%] [12.00dB] [on] Front Right: Capture 39 [62%] [12.00dB] [on] Simple mixer control 'Auto-Mute Mode',0 Capabilities: enum Items: 'Disabled' 'Enabled' Item0: 'Enabled' Simple mixer control 'Internal Mic',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Internal Mic Boost',0 Capabilities: volume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] !!-------Mixer controls for card 1 [HVR950Q] Card hw:1 'HVR950Q'/'Hauppauge HVR-950Q at usb-0000:00:1a.0-1.2.4, high speed' Mixer name : 'USB Mixer' Components : 'USB2040:7200' Controls : 2 Simple ctrls : 1 Simple mixer control 'Digital In',0 Capabilities: cswitch cswitch-joined Capture channels: Mono Mono: Capture [on] !!Alsactl output !!-------------- --startcollapse-- state.PCH { control.1 { iface MIXER name 'Headphone Playback Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 87' dbmin -6525 dbmax 0 dbvalue.0 -6525 dbvalue.1 -6525 } } control.2 { iface MIXER name 'Headphone Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.3 { iface MIXER name 'Speaker Playback Volume' value.0 87 value.1 87 comment { access 'read write' type INTEGER count 2 range '0 - 87' dbmin -6525 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.4 { iface MIXER name 'Speaker Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.5 { iface MIXER name 'Bass Speaker Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.6 { iface MIXER name 'Internal Mic Playback Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -3450 dbmax 1200 dbvalue.0 -3450 dbvalue.1 -3450 } } control.7 { iface MIXER name 'Internal Mic Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.8 { iface MIXER name 'Mic Playback Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -3450 dbmax 1200 dbvalue.0 -3450 dbvalue.1 -3450 } } control.9 { iface MIXER name 'Mic Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.10 { iface MIXER name 'Auto-Mute Mode' value Enabled comment { access 'read write' type ENUMERATED count 1 item.0 Disabled item.1 Enabled } } control.11 { iface MIXER name 'Capture Volume' value.0 39 value.1 39 comment { access 'read write' type INTEGER count 2 range '0 - 63' dbmin -1725 dbmax 3000 dbvalue.0 1200 dbvalue.1 1200 } } control.12 { iface MIXER name 'Capture Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.13 { iface MIXER name 'Internal Mic Boost Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 3' dbmin 0 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.14 { iface MIXER name 'Mic Boost Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 3' dbmin 0 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.15 { iface MIXER name 'Master Playback Volume' value 39 comment { access 'read write' type INTEGER count 1 range '0 - 87' dbmin -6525 dbmax 0 dbvalue.0 -3600 } } control.16 { iface MIXER name 'Master Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.17 { iface CARD name 'Internal Mic Phantom Jack' value true comment { access read type BOOLEAN count 1 } } control.18 { iface CARD name 'Mic Jack' value false comment { access read type BOOLEAN count 1 } } control.19 { iface CARD name 'Headphone Jack' value false comment { access read type BOOLEAN count 1 } } control.20 { iface CARD name 'Speaker Front Phantom Jack' value true comment { access read type BOOLEAN count 1 } } control.21 { iface CARD name 'Speaker Surround Phantom Jack' value true comment { access read type BOOLEAN count 1 } } control.22 { iface PCM name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 comment { access read type INTEGER count 4 range '0 - 36' } } control.23 { iface PCM name 'Capture Channel Map' value.0 0 value.1 0 comment { access read type INTEGER count 2 range '0 - 36' } } control.24 { iface CARD name 'HDMI/DP,pcm=3 Jack' value false comment { access read type BOOLEAN count 1 } } control.25 { iface MIXER name 'IEC958 Playback Con Mask' value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.26 { iface MIXER name 'IEC958 Playback Pro Mask' value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.27 { iface MIXER name 'IEC958 Playback Default' value '0482000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access 'read write' type IEC958 count 1 } } control.28 { iface MIXER name 'IEC958 Playback Switch' value false comment { access 'read write' type BOOLEAN count 1 } } control.29 { iface PCM device 3 name ELD value '' comment { access 'read volatile' type BYTES count 0 } } control.30 { iface PCM device 3 name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 value.4 0 value.5 0 value.6 0 value.7 0 comment { access 'read write' type INTEGER count 8 range '0 - 36' } } control.31 { iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 comment { access 'read write user' type INTEGER count 2 range '0 - 255' tlv '0000000100000008ffffec1400000014' dbmin -5100 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } } state.HVR950Q { control.1 { iface PCM name 'Capture Channel Map' value.0 0 value.1 0 comment { access read type INTEGER count 2 range '0 - 36' } } control.2 { iface MIXER name 'Digital In Capture Switch' value true comment { access 'read write' type BOOLEAN count 1 } } } --endcollapse-- !!All Loaded Modules !!------------------ Module isofs fuse ip6table_filter ip6_tables bnep binfmt_misc vfat fat nouveau arc4 iwldvm snd_usb_audio mac80211 i915 snd_usbmidi_lib snd_rawmidi au8522_dig btusb bluetooth x86_pkg_temp_thermal coretemp kvm_intel kvm xc5000 tuner au8522_decoder au8522_common au0828 tveeprom uvcvideo snd_hda_codec_hdmi snd_hda_codec_realtek videobuf_vmalloc videobuf_core dvb_core snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec iwlwifi snd_hwdep snd_seq ttm videobuf2_vmalloc videobuf2_memops videobuf2_core crct10dif_pclmul cfg80211 snd_seq_device snd_pcm iTCO_wdt i2c_algo_bit drm_kms_helper iTCO_vendor_support snd_timer snd crc32_pclmul crc32c_intel mxm_wmi v4l2_common videodev mei_me mei drm shpchp rfkill soundcore lpc_ich ghash_clmulni_intel media video wmi microcode joydev serio_raw i2c_i801 i2c_core mfd_core r8169 mii !!Sysfs Files !!----------- /sys/class/sound/hwC0D0/init_pin_configs: 0x12 0x411111f0 0x14 0x411111f0 0x15 0x0321101f 0x17 0x90170120 0x18 0x03a11830 0x19 0x90a70940 0x1a 0x411111f0 0x1b 0x90170110 0x1d 0x4006a21d 0x1e 0x411111f0 /sys/class/sound/hwC0D0/driver_pin_configs: /sys/class/sound/hwC0D0/user_pin_configs: /sys/class/sound/hwC0D0/init_verbs: /sys/class/sound/hwC0D0/hints: /sys/class/sound/hwC0D3/init_pin_configs: 0x05 0x18560010 0x06 0x58560020 0x07 0x58560030 /sys/class/sound/hwC0D3/driver_pin_configs: /sys/class/sound/hwC0D3/user_pin_configs: /sys/class/sound/hwC0D3/init_verbs: /sys/class/sound/hwC0D3/hints: !!ALSA/HDA dmesg !!-------------- [ 14.609824] iwlwifi 0000:02:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm [ 14.697168] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002) [ 14.697734] snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X [ 15.418054] sound hdaudioC0D0: autoconfig: line_outs=2 (0x1b/0x17/0x0/0x0/0x0) type:speaker [ 15.418848] sound hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.419460] sound hdaudioC0D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 15.420047] sound hdaudioC0D0: mono: mono_out=0x0 [ 15.420643] sound hdaudioC0D0: inputs: [ 15.421235] sound hdaudioC0D0: Internal Mic=0x19 [ 15.421838] sound hdaudioC0D0: Mic=0x18 [ 15.431094] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6 [ 15.431819] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7 [ 15.431884] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8 [ 15.584383] uvcvideo: Found UVC 1.00 device WebCam SC-13HDL11939N (2232:1029) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 16:24 ` Mauro Carvalho Chehab @ 2014-06-16 17:16 ` Alexander E. Patrakov 2014-06-16 18:59 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 16+ messages in thread From: Alexander E. Patrakov @ 2014-06-16 17:16 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Clemens Ladisch, Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List 16.06.2014 22:24, Mauro Carvalho Chehab wrote: > Em Mon, 16 Jun 2014 20:38:52 +0600 > "Alexander E. Patrakov" <patrakov@gmail.com> escreveu: > >> 16.06.2014 20:21, Mauro Carvalho Chehab wrote: >>> Both xawtv and tvtime use the same code for audio: >>> http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c >>> >>> There's an algorithm there that gets the period size form both the >>> capture and the playback cards, trying to find a minimum period that >>> would work properly for both. >> >> I don't see any adaptive resampler (similar to what module-loopback does >> in pulseaudio) there. > > Are you referring to changing the sample rate? This doesn't > affect my test scenario, as the playback interface supports the > only PCM format/rate used by the TV card (48kHz, 16 bits/sample, stereo): > > Codec: Realtek ALC269VC > Default PCM: > rates [0x5f0]: 32000 44100 48000 88200 96000 192000 > bits [0xe]: 16 20 24 > formats [0x1]: PCM No, it doesn't. The card only pretends to give out samples at 48000 Hz, but, due to the imperfect quartz, actually gives them out at something like 48010 or 47990 Hz (if we take the Realtek's idea of 48 kHz as the source of truth), and that even changes slightly due to thermal issues. The goal here is to measure the actual sample rate and to resample from it to 48 kHz. The "alsaloop" program (part of alsa-utils), when compiled with libsamplerate, does exactly that. If GPLv2+ is OK for you, you can copy the code. >> Without that, or dynamically controlling the audio >> capture clock PLL in the tuner, xruns are unavoidable when transferring >> data between two unrelated cards. > > What do you mean by dynamically controlling the audio capture clock PLL > in the tuner? That doesn't make any sense to me. Some chips (e.g. SAA7133) have a register that allows fine-tuning the actual rate at which they sample the sound (while applications still think that it is nominally at 32 kHz). This register is not exposed at the ALSA level, but exposed as the "audio_clock_tweak" parameter of the saa7134 module. Linux applications normally don't use this register, but Windows uses this register as follows. The official TV playback application, found on the CD with drivers, captures samples from the card into its buffer, and plays from the other end of the buffer concurrently. If there are, on average for a few seconds, too few samples in the buffer, it means that they are consumed faster than they arrive, and so the SAA chip is told to produce them a bit faster. If they accumulate too much, the SAA chip is told to produce them slower. That's it. > > The xc5000 tuner used on this TV device doesn't provide any mechanism > to control audio PLL. It just sends the audio samples to au0828 via a > I2S bus. All the audio control is done by the USB bridge at au0828, > and that is pretty much limited. The only control that au0828 accepts > is the control of the URB buffers (e. g., number of URB packets and > URB size). OK, as you can't tweak the PLL, you have to resample. The idea is, again, simple. Record samples to a buffer if you can, and play them through a variable-rate resampler concurrently if you can. You can use poll() to figure out the "if you can" part. If samples accumulate too much or if the buffer becomes too empty, change the resampling ratio slightly in order to compensate. As I said, the code is here: http://git.alsa-project.org/?p=alsa-utils.git;a=tree;f=alsaloop -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 17:16 ` Alexander E. Patrakov @ 2014-06-16 18:59 ` Mauro Carvalho Chehab 2014-06-16 19:04 ` Devin Heitmueller 0 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-16 18:59 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Clemens Ladisch, Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List Em Mon, 16 Jun 2014 23:16:02 +0600 "Alexander E. Patrakov" <patrakov@gmail.com> escreveu: > 16.06.2014 22:24, Mauro Carvalho Chehab wrote: > > Em Mon, 16 Jun 2014 20:38:52 +0600 > > "Alexander E. Patrakov" <patrakov@gmail.com> escreveu: > > > >> 16.06.2014 20:21, Mauro Carvalho Chehab wrote: > >>> Both xawtv and tvtime use the same code for audio: > >>> http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c > >>> > >>> There's an algorithm there that gets the period size form both the > >>> capture and the playback cards, trying to find a minimum period that > >>> would work properly for both. > >> > >> I don't see any adaptive resampler (similar to what module-loopback does > >> in pulseaudio) there. > > > > Are you referring to changing the sample rate? This doesn't > > affect my test scenario, as the playback interface supports the > > only PCM format/rate used by the TV card (48kHz, 16 bits/sample, stereo): > > > > Codec: Realtek ALC269VC > > Default PCM: > > rates [0x5f0]: 32000 44100 48000 88200 96000 192000 > > bits [0xe]: 16 20 24 > > formats [0x1]: PCM > > No, it doesn't. The card only pretends to give out samples at 48000 Hz, > but, due to the imperfect quartz, actually gives them out at something > like 48010 or 47990 Hz (if we take the Realtek's idea of 48 kHz as the > source of truth), and that even changes slightly due to thermal issues. > The goal here is to measure the actual sample rate and to resample from > it to 48 kHz. I see. Well, you're talking about a xrun that would happen after several seconds, and caused by a clock drift between capture and playback xtals. The issue we're facing happens dozen of times a second, and it is caused by something else: despiste what period_size says, with this board, the sampling period is not continuous. The reason for that is simple: 1ms is the minimal interval for this board can feed interrupts, and the minimal period size = 192 bytes (as anything lower than 192 bytes would cause data to be dropped). As the maximum limit per URB transfer is 3072 bytes (12 URB packs, with 256 bytes each), we have: Period time = (num_bytes + 191) / 192 ms For num_bytes between 192 and 3072. After 3072, the URB endpoint will always use 3072 bytes per URB transfer, with takes 16 ms to be filled. So, the period time is given by: Period time = (num_bytes / 3072) * 16 ms In other words, the period ranges from 1 to 16 ms, in 1ms step, up to 3072 bytes. After that, the period is always multiple of 16 ms. Trying to set it to any value between 17 ms and 31 ms causes xruns, because the buffer will only be filled the next time the URB callback is called (and this happens on every 16 ms). That's what happens with xawtv currently: while the hardware has a 16ms-multiple constraint for the period size, but as there's no constraints at the ALSA Kernel code enforcing a period size multiple of 16 ms, xawtv will set it to its default latency (30 ms). That works fine for the first transfer, but it gets an underrun before the second one. So, we have about 30 underruns per second. There's nothing that can be done on userspace, as the 16 ms multiple request is specific to this card. Other cards use different URB constraints, as different maxsize and/or different number of URBs would result on a different period size. So, changing it in userspace from one card breaks for the others. > The "alsaloop" program (part of alsa-utils), when compiled > with libsamplerate, does exactly that. If GPLv2+ is OK for you, you can > copy the code. After having this big xrun issue fixed, I'll look into it. I need to check if xawtv/tvtime license is GPLv2. > >> Without that, or dynamically controlling the audio > >> capture clock PLL in the tuner, xruns are unavoidable when transferring > >> data between two unrelated cards. > > > > What do you mean by dynamically controlling the audio capture clock PLL > > in the tuner? That doesn't make any sense to me. > > Some chips (e.g. SAA7133) have a register that allows fine-tuning the > actual rate at which they sample the sound (while applications still > think that it is nominally at 32 kHz). This register is not exposed at > the ALSA level, but exposed as the "audio_clock_tweak" parameter of the > saa7134 module. Linux applications normally don't use this register, but > Windows uses this register as follows. > > The official TV playback application, found on the CD with drivers, > captures samples from the card into its buffer, and plays from the other > end of the buffer concurrently. If there are, on average for a few > seconds, too few samples in the buffer, it means that they are consumed > faster than they arrive, and so the SAA chip is told to produce them a > bit faster. If they accumulate too much, the SAA chip is told to produce > them slower. That's it. Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT. > > > > The xc5000 tuner used on this TV device doesn't provide any mechanism > > to control audio PLL. It just sends the audio samples to au0828 via a > > I2S bus. All the audio control is done by the USB bridge at au0828, > > and that is pretty much limited. The only control that au0828 accepts > > is the control of the URB buffers (e. g., number of URB packets and > > URB size). > > OK, as you can't tweak the PLL, you have to resample. The idea is, > again, simple. Record samples to a buffer if you can, and play them > through a variable-rate resampler concurrently if you can. You can use > poll() to figure out the "if you can" part. If samples accumulate too > much or if the buffer becomes too empty, change the resampling ratio > slightly in order to compensate. As I said, the code is here: > > http://git.alsa-project.org/?p=alsa-utils.git;a=tree;f=alsaloop > Ok, I'll look into it after fixing this issue. Regards, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 18:59 ` Mauro Carvalho Chehab @ 2014-06-16 19:04 ` Devin Heitmueller 2014-06-16 19:22 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 16+ messages in thread From: Devin Heitmueller @ 2014-06-16 19:04 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Alexander E. Patrakov, Clemens Ladisch, Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List >> The official TV playback application, found on the CD with drivers, >> captures samples from the card into its buffer, and plays from the other >> end of the buffer concurrently. If there are, on average for a few >> seconds, too few samples in the buffer, it means that they are consumed >> faster than they arrive, and so the SAA chip is told to produce them a >> bit faster. If they accumulate too much, the SAA chip is told to produce >> them slower. That's it. > > Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT. > >> > >> > The xc5000 tuner used on this TV device doesn't provide any mechanism >> > to control audio PLL. It just sends the audio samples to au0828 via a >> > I2S bus. All the audio control is done by the USB bridge at au0828, >> > and that is pretty much limited. The only control that au0828 accepts >> > is the control of the URB buffers (e. g., number of URB packets and >> > URB size). It's probably worth noting that Mauro's explanation here is incorrect - the xc5000 does *not* put out I2S. It outputs an SIF which is fed to the au8522. The au8522 has the audio decoder, and it's responsible for putting out I2S to the au0828. Hence the xc5000's PLL would have no role here. In fact, you should see the exact same behavior on the A/V input, since the au8522 is responsible for the I2S clock which drives the cs5503 (the 5503 is in slave mode). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 19:04 ` Devin Heitmueller @ 2014-06-16 19:22 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-16 19:22 UTC (permalink / raw) To: Devin Heitmueller Cc: Alexander E. Patrakov, Clemens Ladisch, Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List Em Mon, 16 Jun 2014 15:04:44 -0400 Devin Heitmueller <dheitmueller@kernellabs.com> escreveu: > >> The official TV playback application, found on the CD with drivers, > >> captures samples from the card into its buffer, and plays from the other > >> end of the buffer concurrently. If there are, on average for a few > >> seconds, too few samples in the buffer, it means that they are consumed > >> faster than they arrive, and so the SAA chip is told to produce them a > >> bit faster. If they accumulate too much, the SAA chip is told to produce > >> them slower. That's it. > > > > Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT. > > > >> > > >> > The xc5000 tuner used on this TV device doesn't provide any mechanism > >> > to control audio PLL. It just sends the audio samples to au0828 via a > >> > I2S bus. All the audio control is done by the USB bridge at au0828, > >> > and that is pretty much limited. The only control that au0828 accepts > >> > is the control of the URB buffers (e. g., number of URB packets and > >> > URB size). > > It's probably worth noting that Mauro's explanation here is incorrect > - the xc5000 does *not* put out I2S. It outputs an SIF which is fed > to the au8522. The au8522 has the audio decoder, and it's responsible > for putting out I2S to the au0828. > > Hence the xc5000's PLL would have no role here. > Ah, OK. I didn't notice that hvr950q was using SIF. In this case, then maybe au8522 may have some PLL fine tune register to adjust the sampling rate. > In fact, you should see the exact same behavior on the A/V input, > since the au8522 is responsible for the I2S clock which drives the > cs5503 (the 5503 is in slave mode). I suspect that the best is to use a resampling code to avoid the frequency drift clock issue, as it is generic enough to cover both cases, and won't require hardware-assisted support. Yet, as I posted on my previous email, this is not yet the kind of bug that we're facing right now. If I'm doing the calculus correct, a -10Hz difference at a 48 kHz sampling rate would take ~150 seconds to cause an underrun (a 16 ms period_bytes lost). Regards, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes 2014-06-16 14:21 ` Mauro Carvalho Chehab 2014-06-16 14:38 ` Alexander E. Patrakov @ 2014-06-18 8:21 ` Clemens Ladisch 1 sibling, 0 replies; 16+ messages in thread From: Clemens Ladisch @ 2014-06-18 8:21 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Takashi Iwai, alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List Mauro Carvalho Chehab wrote: > Both xawtv and tvtime use the same code for audio: > http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c > > There's an algorithm there that gets the period size form both the > capture and the playback cards, trying to find a minimum period that > would work properly for both. Why are you trying to match period sizes? The sample clocks won't be synchronized anyway, so it is not possible to force them to happen at the same time. Please note that for playback devices, the latency is the same as the buffer length, while for capture device, the latency is the same as the _period_ length. Therefore, it does not make sense to put an upper limit on the size of the capture buffer. I do not think it is a good idea to stop the capture device when it overruns. Regards, Clemens ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/3] sound: simplify au0828 quirk table 2014-06-14 16:16 [PATCH 0/3] Auvitek au0828 fixups Mauro Carvalho Chehab 2014-06-14 16:16 ` [PATCH 1/3] sound: Add a quirk to enforce period_bytes Mauro Carvalho Chehab @ 2014-06-14 16:16 ` Mauro Carvalho Chehab 2014-06-14 16:16 ` [PATCH 3/3] sound: Update au0828 quirks table Mauro Carvalho Chehab 2 siblings, 0 replies; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-14 16:16 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List, Mauro Carvalho Chehab, stable Add a macro to simplify au0828 quirk table. That makes easier to check it against the USB IDs at drivers/media/usb/au0828-card.c Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> --- sound/usb/quirks-table.h | 159 ++++++++++------------------------------------- 1 file changed, 32 insertions(+), 127 deletions(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 236adf61d27a..30add0bfee8e 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -232,6 +232,7 @@ * Yamaha devices */ + #define YAMAHA_DEVICE(id, name) { \ USB_DEVICE(0x0499, id), \ .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { \ @@ -2745,133 +2746,37 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, -/* Hauppauge HVR-950Q and HVR-850 */ -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x7200), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x7210), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x7217), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x721b), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x721e), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x721f), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x7240), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-850", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x2040, 0x7280), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, -{ - USB_DEVICE_VENDOR_SPEC(0x0fd9, 0x0008), - .match_flags = USB_DEVICE_ID_MATCH_DEVICE | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_SUBCLASS, - .bInterfaceClass = USB_CLASS_AUDIO, - .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, - .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { - .vendor_name = "Hauppauge", - .product_name = "HVR-950Q", - .ifnum = QUIRK_ANY_INTERFACE, - .type = QUIRK_AUDIO_AUVITEK_0828, - } -}, +/* + * Auvitek au0828 devices with audio interface. + * This should be kept in sync with drivers/media/usb/au0828-card.c + * Please notice that some drivers are DVB only, and don't need to be + * here. That's the case, for example, of DVICO_FUSIONHDTV7. + */ + +#define AU0828_DEVICE(vid, pid, vname, pname) { \ + USB_DEVICE_VENDOR_SPEC(vid, pid), \ + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \ + USB_DEVICE_ID_MATCH_INT_CLASS | \ + USB_DEVICE_ID_MATCH_INT_SUBCLASS, \ + .bInterfaceClass = USB_CLASS_AUDIO, \ + .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, \ + .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { \ + .vendor_name = vname, \ + .product_name = pname, \ + .ifnum = QUIRK_ANY_INTERFACE, \ + .type = QUIRK_AUDIO_AUVITEK_0828, \ + } \ +} + +AU0828_DEVICE(0x2040, 0x7200, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x7210, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x7217, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x721b, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x721e, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x721f, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x7240, "Hauppauge", "HVR-850"), +AU0828_DEVICE(0x2040, 0x7280, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x0fd9, 0x0008, "Hauppauge", "HVR-950Q"), /* Digidesign Mbox */ { -- 1.9.3 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 3/3] sound: Update au0828 quirks table 2014-06-14 16:16 [PATCH 0/3] Auvitek au0828 fixups Mauro Carvalho Chehab 2014-06-14 16:16 ` [PATCH 1/3] sound: Add a quirk to enforce period_bytes Mauro Carvalho Chehab 2014-06-14 16:16 ` [PATCH 2/3] sound: simplify au0828 quirk table Mauro Carvalho Chehab @ 2014-06-14 16:16 ` Mauro Carvalho Chehab 2 siblings, 0 replies; 16+ messages in thread From: Mauro Carvalho Chehab @ 2014-06-14 16:16 UTC (permalink / raw) To: Takashi Iwai Cc: alsa-devel, Mauro Carvalho Chehab, Linux Media Mailing List, Mauro Carvalho Chehab, stable The au0828 quirks table is currently not in sync with the au0828 media driver. Syncronize it, as all the au0828 devices with analog TV need the same quirks. Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> --- sound/usb/quirks-table.h | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 30add0bfee8e..3f882d996981 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2769,14 +2769,22 @@ YAMAHA_DEVICE(0x7010, "UB99"), } AU0828_DEVICE(0x2040, 0x7200, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x7240, "Hauppauge", "HVR-850"), AU0828_DEVICE(0x2040, 0x7210, "Hauppauge", "HVR-950Q"), AU0828_DEVICE(0x2040, 0x7217, "Hauppauge", "HVR-950Q"), AU0828_DEVICE(0x2040, 0x721b, "Hauppauge", "HVR-950Q"), AU0828_DEVICE(0x2040, 0x721e, "Hauppauge", "HVR-950Q"), AU0828_DEVICE(0x2040, 0x721f, "Hauppauge", "HVR-950Q"), -AU0828_DEVICE(0x2040, 0x7240, "Hauppauge", "HVR-850"), AU0828_DEVICE(0x2040, 0x7280, "Hauppauge", "HVR-950Q"), AU0828_DEVICE(0x0fd9, 0x0008, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x7201, "Hauppauge", "HVR-950Q-MXL"), +AU0828_DEVICE(0x2040, 0x7211, "Hauppauge", "HVR-950Q-MXL"), +AU0828_DEVICE(0x2040, 0x7281, "Hauppauge", "HVR-950Q-MXL"), +AU0828_DEVICE(0x05e1, 0x0480, "Hauppauge", "Woodbury"), +AU0828_DEVICE(0x2040, 0x8200, "Hauppauge", "Woodbury"), +AU0828_DEVICE(0x2040, 0x7260, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x7213, "Hauppauge", "HVR-950Q"), +AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"), /* Digidesign Mbox */ { -- 1.9.3 ^ permalink raw reply related [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-06-18 8:21 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-14 16:16 [PATCH 0/3] Auvitek au0828 fixups Mauro Carvalho Chehab 2014-06-14 16:16 ` [PATCH 1/3] sound: Add a quirk to enforce period_bytes Mauro Carvalho Chehab 2014-06-16 7:39 ` [alsa-devel] " Clemens Ladisch 2014-06-16 13:22 ` Devin Heitmueller 2014-06-16 15:05 ` [alsa-devel] " Mauro Carvalho Chehab 2014-06-18 8:20 ` Clemens Ladisch 2014-06-16 14:21 ` Mauro Carvalho Chehab 2014-06-16 14:38 ` Alexander E. Patrakov 2014-06-16 16:24 ` Mauro Carvalho Chehab 2014-06-16 17:16 ` Alexander E. Patrakov 2014-06-16 18:59 ` Mauro Carvalho Chehab 2014-06-16 19:04 ` Devin Heitmueller 2014-06-16 19:22 ` Mauro Carvalho Chehab 2014-06-18 8:21 ` Clemens Ladisch 2014-06-14 16:16 ` [PATCH 2/3] sound: simplify au0828 quirk table Mauro Carvalho Chehab 2014-06-14 16:16 ` [PATCH 3/3] sound: Update au0828 quirks table Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).