On 10/31/2014 12:13 AM, Tim Harvey wrote:
On Thu, Oct 30, 2014 at 12:41 AM, Lars-Peter Clausen lars@metafoo.de wrote:
On 10/30/2014 04:34 AM, Tim Harvey wrote:
Greetings,
I'm working on an ASoC driver (an mfd driver for an HDMI receiver chip with an accompanying codec driver for the audio capture portion, and a cpu-dai driver for the specific SoC its hooked to). I can't seem to figure out what kind of hook I need in order to fill out the snd_pcm_substream fields specifying the rate/channels/sample-format of the receiving HDMI audio stream. In this case HDMI audio (and thus the codec) supports several rates but it doesn't make sense that the codec is told what rate to capture at as the rate is dictated by the current stream the receiver is being provided. I'm thinking there is some hook I'm missing that allows the codec to fill in the params dynamically when the capture device is opened.
Any pointers to how I deal with this?
In the startup() callback of the CODEC driver you can apply additional constraints to the available parameter ranges. See snd_pcm_hw_constraints_... in include/sound/pcm.h
E.g. to constrain the rate to one fixed value you could do snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_RATE, rate, rate);
- Lars
Lars,
Thanks for the tip!
I found that if I add some validation into the hw_params function for the codec, that I can return an -EINVAL if the requested params don't match the incoming stream and that will cause the ALSA application to at least error out.
However, when I saw your response I then also tried setting the constraint and found that an invalid sample-rate gets 'refined' to the available rate thus the hw_params sanity check passes, yet the user application apparently does not feedback that the rate has been changed.
For example if I do the following on a capture stream which is actually 44.1kHz from the HDMI source with a constraint to set the rate to 44100 the audio is played back at 44100 and has all kinds of pops etc:
gst-launch alsasrc device="my-hdmi-receiver-card" ! audio/x-raw-int,rate=48000 ! queue ! alsasink device="playback-card"
Where-as the following plays back fine:
gst-launch alsasrc device="my-hdmi-receiver-card" ! audio/x-raw-int,rate=44100 ! queue ! alsasink device="playback-card"
I find that the value passed to startup in the substream is 48000 which gets refined to 44100 if the constraints were set, which ends up passing hw_params 44100 but the 'application' still has issues.
I think its more appropriate to validate the hw_params instead of using the constraints. Does this make sense?
No. By setting up the constraints you tell the userspace application which parameters are supported. This allows the application to pick one of the available parameters and then call hw_params() with it. Not setting up the constraints and erroring out in hw_params() will cause applications to not work. If the rate requested is not in the valid range the ALSA core should actually already error out before the drivers hw_params() function is called.
- Lars