[alsa-devel] [PATCH] ASoC: define playback and capture streams in dummy codec
Hi.
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
Signed-off-by: Stas Sergeev stsp@users.sourceforge.net
On Fri, Apr 12, 2013 at 02:53:56PM +0400, Stas Sergeev wrote:
Hi.
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
The changelog ought to explain why this is required...
Signed-off-by: Stas Sergeev stsp@users.sourceforge.net
Please send patches as documented in SubmittingPatches - even as an attachment this isn't coming out as plain text for me.
On Fri, 12 Apr 2013 11:59:44 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
The changelog ought to explain why this is required...
I can only tell that without this patch I am not getting any sound at all... which is probably a rather poor statement for the changelog. Could you please correct the changelog with the better knowledge of the details?
Signed-off-by: Stas Sergeev stsp@users.sourceforge.net
Please send patches as documented in SubmittingPatches - even as an attachment this isn't coming out as plain text for me.
OK, now it should be as a plain text.
On 04/12/2013 07:19 AM, Stas Sergeev wrote:
On Fri, 12 Apr 2013 11:59:44 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
The changelog ought to explain why this is required...
I can only tell that without this patch I am not getting any sound at all... which is probably a rather poor statement for the changelog. Could you please correct the changelog with the better knowledge of the details?
He means that the commit message. Your commit message says what the patch does. It does not say why the patch is needed.
-gabriel
12.04.2013 19:13, Gabriel M. Beddingfield пишет:
On 04/12/2013 07:19 AM, Stas Sergeev wrote:
On Fri, 12 Apr 2013 11:59:44 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
The changelog ought to explain why this is required...
I can only tell that without this patch I am not getting any sound at all... which is probably a rather poor statement for the changelog. Could you please correct the changelog with the better knowledge of the details?
He means that the commit message. Your commit message says what the patch does. It does not say why the patch is needed.
Yes. But what should I add to the commit message, if the only thing I know about this patch, is that I am not getting any sound without it? :) The reason should be obvious for whoever is familiar with that subsystem, but its not me.
On 04/12/2013 08:20 AM, Stas Sergeev wrote:
He means that the commit message. Your commit message says what the patch does. It does not say why the patch is needed.
Yes. But what should I add to the commit message, if the only thing I know about this patch, is that I am not getting any sound without it? :) The reason should be obvious for whoever is familiar with that subsystem, but its not me.
Yep, just formalize the "I am not getting any sound with it" statement. :-) Maybe something like: "Because snd-soc-dummy didn't declare any DAI, it was unable to be used for any audio streams."
-gabriel
12.04.2013 19:24, Gabriel M. Beddingfield пишет:
On 04/12/2013 08:20 AM, Stas Sergeev wrote:
He means that the commit message. Your commit message says what the patch does. It does not say why the patch is needed.
Yes. But what should I add to the commit message, if the only thing I know about this patch, is that I am not getting any sound without it? :) The reason should be obvious for whoever is familiar with that subsystem, but its not me.
Yep, just formalize the "I am not getting any sound with it" statement. :-)
Hi, Would something like the attached patch be good to help formalizing this? With that patch I am getting: --- [ 2.800190] asoc: no playback or capture streams available [ 2.805158] asoc: can't create pcm Pri_Dai [ 2.809241] asoc: failed to instantiate card I2S: -22 --- which is much better than before. If I get any ACKs on this one, I'll submit it too.
On 04/12/2013 05:20 PM, Stas Sergeev wrote:
12.04.2013 19:13, Gabriel M. Beddingfield пишет:
On 04/12/2013 07:19 AM, Stas Sergeev wrote:
On Fri, 12 Apr 2013 11:59:44 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
The changelog ought to explain why this is required...
I can only tell that without this patch I am not getting any sound at all... which is probably a rather poor statement for the changelog. Could you please correct the changelog with the better knowledge of the details?
He means that the commit message. Your commit message says what the patch does. It does not say why the patch is needed.
Yes. But what should I add to the commit message, if the only thing I know about this patch, is that I am not getting any sound without it? :) The reason should be obvious for whoever is familiar with that subsystem, but its not me.
Well, if not explicitly initialized a field is set to 0. Which is kind of the most restrictive option for many of the fields. E.g. channels_max, rates, formats, etc. When the ASoC core creates a new PCM device it will take the intersection of the CPU DAI and CODEC DAI fields to initialize the fields the PCM. So if for example channels_max is 0 for the CODEC DAI, channels_max will also be 0 for the PCM, no matter what channels_max is set to for the CPU DAI. Same goes for formats and rates. So a dummy CODEC should have set its fields in a way that it is most permissive, so that the intersection of the CODEC DAI fields with the CPU DAI fields will be equal to the CPU DAI fields.
- Lars
On Fri, 12 Apr 2013 17:31:19 +0200 Lars-Peter Clausen lars@metafoo.de wrote:
Well, if not explicitly initialized a field is set to 0. Which is kind of the most restrictive option for many of the fields. E.g. channels_max, rates, formats, etc. When the ASoC core creates a new PCM device it will take the intersection of the CPU DAI and CODEC DAI fields to initialize the fields the PCM. So if for example channels_max is 0 for the CODEC DAI, channels_max will also be 0 for the PCM, no matter what channels_max is set to for the CPU DAI. Same goes for formats and rates. So a dummy CODEC should have set its fields in a way that it is most permissive, so that the intersection of the CODEC DAI fields with the CPU DAI fields will be equal to the CPU DAI fields.
Thanks for an explanation! But what happens when the DAI is considered mute by the effect of such intersection? From what I can see, no callbacks from the DAI driver are called in this case (this is expected), but no error is returned to userspace, and, more importantly, the playback speed is still correct, so the userspace can get a playback position as if the playback is fine. While during the normal playback, if I stop calling snd_pcm_period_elapsed(), userspace is no longer getting the right position. That's why I am confused, I can't easily explain this "no sound but otherwise fine playback" effect, so I am a bit reluctant to try explaining this in a commit msg. Are there are some fallbacks? Such as when the DAI is considered mute, it gets somehow emulated, with the use of the system clock for correct timing etc?
On 04/12/2013 06:37 PM, Stas Sergeev wrote:
On Fri, 12 Apr 2013 17:31:19 +0200 Lars-Peter Clausen lars@metafoo.de wrote:
Well, if not explicitly initialized a field is set to 0. Which is kind of the most restrictive option for many of the fields. E.g. channels_max, rates, formats, etc. When the ASoC core creates a new PCM device it will take the intersection of the CPU DAI and CODEC DAI fields to initialize the fields the PCM. So if for example channels_max is 0 for the CODEC DAI, channels_max will also be 0 for the PCM, no matter what channels_max is set to for the CPU DAI. Same goes for formats and rates. So a dummy CODEC should have set its fields in a way that it is most permissive, so that the intersection of the CODEC DAI fields with the CPU DAI fields will be equal to the CPU DAI fields.
Thanks for an explanation! But what happens when the DAI is considered mute by the effect of such intersection? From what I can see, no callbacks from the DAI driver are called in this case (this is expected), but no error is returned to userspace, and, more importantly, the playback speed is still correct, so the userspace can get a playback position as if the playback is fine. While during the normal playback, if I stop calling snd_pcm_period_elapsed(), userspace is no longer getting the right position. That's why I am confused, I can't easily explain this "no sound but otherwise fine playback" effect, so I am a bit reluctant to try explaining this in a commit msg. Are there are some fallbacks? Such as when the DAI is considered mute, it gets somehow emulated, with the use of the system clock for correct timing etc?
That's actually a bit strange indeed, since you should get an error when you try to open the pcm device.
- Lars
12.04.2013 20:55, Lars-Peter Clausen пишет:
On 04/12/2013 06:37 PM, Stas Sergeev wrote:
Thanks for an explanation! But what happens when the DAI is considered mute by the effect of such intersection? From what I can see, no callbacks from the DAI driver are called in this case (this is expected), but no error is returned to userspace, and, more importantly, the playback speed is still correct, so the userspace can get a playback position as if the playback is fine. While during the normal playback, if I stop calling snd_pcm_period_elapsed(), userspace is no longer getting the right position. That's why I am confused, I can't easily explain this "no sound but otherwise fine playback" effect, so I am a bit reluctant to try explaining this in a commit msg. Are there are some fallbacks? Such as when the DAI is considered mute, it gets somehow emulated, with the use of the system clock for correct timing etc?
That's actually a bit strange indeed, since you should get an error when you try to open the pcm device.
Ah great! Next week I'll double-check that the fall-back is actually in userspace (in an android media stack perhaps), and that will be enough info for the reasonable commit msg. :) Thanks for your help!
Hello.
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
This patch is needed for playback and capturing on a codec-less systems, as otherwise the PCM device nodes are not even created.
Signed-off-by: Stas Sergeev stsp@users.sourceforge.net
On Wed, Apr 17, 2013 at 04:34:06PM +0400, Stas Sergeev wrote:
This patch adds a playback and capture streams to the dummy codec DAI configuration. Most permissive set of sampling rates and formats is used.
This patch is needed for playback and capturing on a codec-less systems, as otherwise the PCM device nodes are not even created.
Signed-off-by: Stas Sergeev stsp@users.sourceforge.net
From 9a498275e59c2c6ef933fe7d0cff79a13ba790ff Mon Sep 17 00:00:00 2001 From: Stas Sergeev stsp@users.sourceforge.net Date: Thu, 11 Apr 2013 19:07:20 +0400 Subject: [PATCH] ASoC: define playback and capture streams in dummy codec
Applied, but please do send patches as covered in SubmittingPatches - send patches inline, not as attachments. That makes them harder to apply.
participants (5)
-
Gabriel M. Beddingfield -
Lars-Peter Clausen -
Mark Brown -
Mark Brown -
Stas Sergeev