Stream format conversion in SoC driver

Stream format conversion in SoC driver

[Giedrius Trainavičius]

Hi,

We are developing a soundcard for Raspberry Pi, you may find the current
driver source code here:
https://github.com/raspberrypi/linux/blob/rpi-4.4.y/sound/soc/bcm/pisound.c

The card natively supports 24 and 32 bit PCM streams at 48kHz, 96kHz and
192kHz, symmetric capture and playback.

Is it possible to have ALSA do the necessary format conversions for the PCM
streams in natively unsupported formats to the closest natively supported
format?

What would be required to enable it?

Thank you,
Giedrius.

Re: Stream format conversion in SoC driver

[Clemens Ladisch]

Giedrius Trainavičius" wrote:
>Is it possible to have ALSA do the necessary format conversions for the PCM
>streams in natively unsupported formats to the closest natively supported
>format?

Yes (in userspace).

>What would be required to enable it?

Nothing; the "plug" plugin is automatically used by the
default device.


Regards,
Clemens

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Giedrius Trainavičius]

Unfortunately the 'volumealsa' widget used by Raspbian does not support
'plug' in .asoundrc... (
https://github.com/raspberrypi/lxpanel/blob/master/plugins/volumealsa/volumealsa.c)
It hardcodes default device to type 'hw'.

I hoped I could get transcoding getting done within the kernel space, then
no changes to Raspbian's 'volumealsa' would be needed...

Is there any other way possible?

Thank you,
Giedrius.

On Tue, Dec 27, 2016 at 10:51 PM, Clemens Ladisch <clemens@ladisch.de>
wrote:

> Giedrius Trainavičius" wrote:
> >Is it possible to have ALSA do the necessary format conversions for the
> PCM
> >streams in natively unsupported formats to the closest natively supported
> >format?
>
> Yes (in userspace).
>
> >What would be required to enable it?
>
> Nothing; the "plug" plugin is automatically used by the
> default device.
>
>
> Regards,
> Clemens
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Clemens Ladisch]

Giedrius Trainavičius wrote:
>Unfortunately the 'volumealsa' widget used by Raspbian does not support
>'plug' in .asoundrc...

There are no plugins for control devices because those are used
only to access mixer controls.

How do you play sounds?


Regards,
Clemens

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Giedrius Trainavičius]

What we want to achieve is for user to be able to select our sound card in
the 'volumealsa' widget and all the software, such as internet browsers,
mplayer, etc... would by default, without any further configuration, be
able to output sound as usual.

To achieve that, there seems to be 2 ways:

1. Report that S16_LE format is supported, somehow internally do the sample
format conversion in kernel space.
2. Use 'plug' in .asoundrc, and make changes to volumealsa widget in RPI
fork to be compatible with it.

If at all possible, the 1st option would be preferred, as it would involve
less parties.

Thank you,
Giedrius.


On Wed, Dec 28, 2016 at 4:22 PM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Giedrius Trainavičius wrote:
> >Unfortunately the 'volumealsa' widget used by Raspbian does not support
> >'plug' in .asoundrc...
>
> There are no plugins for control devices because those are used
> only to access mixer controls.
>
> How do you play sounds?
>
>
> Regards,
> Clemens
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Clemens Ladisch]

Giedrius Trainavičius wrote:
>What we want to achieve is for user to be able to select our sound card in
>the 'volumealsa' widget and all the software, such as internet browsers,
>mplayer, etc... would by default, without any further configuration, be
>able to output sound as usual.

I've looked at that widget's source, and it indeed hardcodes "hw" when
switching cards.

(It's possible that sample rate conversion is seen as using too
much CPU.)

The correct way to set the default card would be defaults.pcm.card,
but this might not work with customized conf files.

What hardware bus does your device use?
Doesn't the I2S/DMA controller support 16-bit samples?


Regards,
Clemens

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Clemens Ladisch]

Giedrius Trainavičius wrote:
>It uses I2S for sending / receiving audio. However, the master clock on our
>sound card is generated by the ADC, which supports only 24 bit data, so
>getting other sample formats is not possible.

The I2S sample format need not be the same as what the DMA
controller reads/writes from/to memory.

>A question on 'plug' - it accepts 'nearest' as the argument for format,
>rate, what happens in case the slave pcm stream supports the exact same
>format as requested by user software?

The plug plugin instantiates the actual conversion plugins only
as needed; with no conversion, it vanishes entirely.


Regards,
Clemens

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Giedrius Trainavičius]

The I2S and DMA format asymmetry sounds like what I'd be after. Do you have
any pointers for APIs / keywords to look around for in the code to see how
this should be set up? Is such format conversion supposed to be happening
in hardware itself, or the CPU when accessing the DMA buffer has the chance
to do the conversion?

The relevant documentation and code I found so far would be:

https://www.raspberrypi.org/documentation/hardware/
raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf
https://github.com/raspberrypi/linux/blob/rpi-4.
4.y/sound/soc/bcm/bcm2835-i2s.c

I can't locate any relevant bits of code or information that'd indicate
capabilities of sample format conversion...

Thank you,
Giedrius.

On Thu, Dec 29, 2016 at 7:53 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Giedrius Trainavičius wrote:
> >It uses I2S for sending / receiving audio. However, the master clock on
> our
> >sound card is generated by the ADC, which supports only 24 bit data, so
> >getting other sample formats is not possible.
>
> The I2S sample format need not be the same as what the DMA
> controller reads/writes from/to memory.
>
> >A question on 'plug' - it accepts 'nearest' as the argument for format,
> >rate, what happens in case the slave pcm stream supports the exact same
> >format as requested by user software?
>
> The plug plugin instantiates the actual conversion plugins only
> as needed; with no conversion, it vanishes entirely.
>
>
> Regards,
> Clemens
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Giedrius Trainavičius]

Hey,

Any thoughts or pointers on what to look for in order to use different
sample format between actual I2S and DMA?

Thank you,
Giedrius.

On Thu, Dec 29, 2016 at 4:32 PM, Giedrius Trainavičius <
giedrius.trainavicius@gmail.com> wrote:

> The I2S and DMA format asymmetry sounds like what I'd be after. Do you
> have any pointers for APIs / keywords to look around for in the code to see
> how this should be set up? Is such format conversion supposed to be
> happening in hardware itself, or the CPU when accessing the DMA buffer has
> the chance to do the conversion?
>
> The relevant documentation and code I found so far would be:
>
> https://www.raspberrypi.org/documentation/hardware/raspberry
> pi/bcm2835/BCM2835-ARM-Peripherals.pdf
> https://github.com/raspberrypi/linux/blob/rpi-4.4.y/sound/
> soc/bcm/bcm2835-i2s.c
>
> I can't locate any relevant bits of code or information that'd indicate
> capabilities of sample format conversion...
>
> Thank you,
> Giedrius.
>
> On Thu, Dec 29, 2016 at 7:53 AM, Clemens Ladisch <clemens@ladisch.de>
> wrote:
>
>> Giedrius Trainavičius wrote:
>> >It uses I2S for sending / receiving audio. However, the master clock on
>> our
>> >sound card is generated by the ADC, which supports only 24 bit data, so
>> >getting other sample formats is not possible.
>>
>> The I2S sample format need not be the same as what the DMA
>> controller reads/writes from/to memory.
>>
>> >A question on 'plug' - it accepts 'nearest' as the argument for format,
>> >rate, what happens in case the slave pcm stream supports the exact same
>> >format as requested by user software?
>>
>> The plug plugin instantiates the actual conversion plugins only
>> as needed; with no conversion, it vanishes entirely.
>>
>>
>> Regards,
>> Clemens
>>
>>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Clemens Ladisch]

Giedrius Trainavičius wrote:
> The I2S and DMA format asymmetry sounds like what I'd be after. Do you have
> any pointers for APIs / keywords to look around for in the code to see how
> this should be set up?

This is typically done in the hw_params callback.

> Is such format conversion supposed to be happening in hardware itself

Yes; see figure 8-1:
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf


Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Stream format conversion in SoC driver

[Giedrius Trainavičius]

Great! I managed to get 16 bit output to work just fine! Thank you!

After investigating related code and the PCM registers documentation,
turned out all I had to do was to call:

snd_soc_dai_set_bclk_ratio(dai, 32*2); // 32 bits for each of 2 channels

I've seen this method before, but its use / meaning wasn't obvious at
first...

However, recording using ADC generating 64 bit frames, 24 bit samples,
didn't work as expected when using 16bits... (it was producing noise mostly
in one channel, and less noise in the other) I haven't yet investigated
why, but will do.

Any way I can provide different sample format constraints for playback and
capture? (until 16 bit recording issue is resolved)

Thank you,
Giedrius.
​
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel