[PATCH 0/3] Auvitek au0828 fixups

[PATCH 0/3] Auvitek au0828 fixups

[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

[PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Mauro Carvalho Chehab]

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

[PATCH 2/3] sound: simplify au0828 quirk table

[Mauro Carvalho Chehab]

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

[PATCH 3/3] sound: Update au0828 quirks table

[Mauro Carvalho Chehab]

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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Clemens Ladisch]

(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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Devin Heitmueller]

> 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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Alexander E. Patrakov]

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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Mauro Carvalho Chehab]

[-- 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)

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Alexander E. Patrakov]

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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Mauro Carvalho Chehab]

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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Devin Heitmueller]

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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Mauro Carvalho Chehab]

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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Clemens Ladisch]

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

Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes

[Clemens Ladisch]

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