[pulseaudio-discuss] Why are we checking various sample rates?

[Damir Jelić]

On Sun, Dec 02, 2012 at 05:10:53AM +0200, Tanu Kaskinen wrote:
> On Fri, 2012-11-30 at 09:59 +0100, David Henningsson wrote:
> > Hi,
> > 
> > I'm researching a bug where some set of USB speakers stopped working, 
> > probably in 2.x. The peculiar thing about this sound card is that seems 
> > to only work at a sample rate of 46875 Hz.
> > 
> > So in 2.x, the probe fails with
> > "E: [pulseaudio] alsa-sink.c: Failed to find any supported sample 
> > rates.", whereas in an earlier version, it would just happily work at 
> > 46875 Hz instead, as I understand it.
> > 
> > So my first question is; why do we check all these rates, when we end up 
> > just alternating between default-sample-rate (44100 Hz) and 
> > alternate-sample-rate (48000 Hz) anyway?
> 
> I don't have an answer for that.
> 
> > And second, can we try not to fail if we can't find any supported sample 
> > rates, so we can fix this regression?
> 
> I don't see any fundamental reason why we couldn't support any crazy
> sample rate.
> 
> > For reference, this is the bug (with pulse verbose logs in it):
> > 
> > https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1074783
> 
> A related bug: https://bugs.freedesktop.org/show_bug.cgi?id=48109
> 
> -- 
> Tanu
> 
Hi.
I played around a bit and found seemingly a solution to this. I'm not sure
if this is the proper solution but it seems to work for me. Let me know
if I should clean this up a little further.

Patch attached.
-------------- next part --------------
>From 6a2a994592564d0534fc5308e909e38067bcdc18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?poljar=20=28Damir=20Jeli=C4=87=29?= <poljarinho at gmail.com>
Date: Sun, 2 Dec 2012 21:56:46 +0100
Subject: [PATCH] alsa: Find all supported sink/source sample rates.

This is needed for some obscure hardware that supports only weird sample
rates.
Instead of relying on a static rates list we get the min/max supported
sample rate from alsa and probe every rate inbetween.

The static list is still used as a fallback if we don't get proper
min/max rates from alsa.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=48109
---
 src/modules/alsa/alsa-util.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/src/modules/alsa/alsa-util.c b/src/modules/alsa/alsa-util.c
index 4a29a9a..ca6a3bb 100644
--- a/src/modules/alsa/alsa-util.c
+++ b/src/modules/alsa/alsa-util.c
@@ -1335,8 +1335,8 @@ unsigned int *pa_alsa_get_supported_rates(snd_pcm_t *pcm) {
                                         384000 };
     pa_bool_t supported[PA_ELEMENTSOF(all_rates)] = { FALSE, };
     snd_pcm_hw_params_t *hwparams;
-    unsigned int i, j, n, *rates = NULL;
-    int ret;
+    unsigned int i, j, n, *rates = NULL, rate_min, rate_max;
+    int ret, dir;
 
     snd_pcm_hw_params_alloca(&hwparams);
 
@@ -1345,6 +1345,30 @@ unsigned int *pa_alsa_get_supported_rates(snd_pcm_t *pcm) {
         return NULL;
     }
 
+    if ((ret =snd_pcm_hw_params_get_rate_min(hwparams, &rate_min, &dir)) < 0) {
+        pa_log_debug("snd_pcm_hw_params_get_rate_min() failed: %s", pa_alsa_strerror(ret));
+        goto fallback;
+    }
+
+    if ((ret =snd_pcm_hw_params_get_rate_max(hwparams, &rate_max, &dir)) < 0) {
+        pa_log_debug("snd_pcm_hw_params_get_rate_max() failed: %s", pa_alsa_strerror(ret));
+        goto fallback;
+    }
+    pa_log_debug("Found min - max rates: %d - %d", rate_min, rate_max);
+
+    for (i = rate_min, n = 0; i <= rate_max; i++) {
+        if (snd_pcm_hw_params_test_rate(pcm, hwparams, i, 0) == 0) {
+            rates = pa_xrealloc(rates, ++n * sizeof(unsigned int));
+            rates[n-1] = i;
+        }
+    }
+    /* This is here to check if we get bogus min/max rates */
+    if (n == 0)
+        goto fallback;
+
+    return rates;
+
+fallback:
     for (i = 0, n = 0; i < PA_ELEMENTSOF(all_rates); i++) {
         if (snd_pcm_hw_params_test_rate(pcm, hwparams, all_rates[i], 0) == 0) {
             supported[i] = TRUE;
-- 
1.8.0.1