[alsa-devel] mono/stereo translation & number of frames per period
I thought that simply by reporting that my driver only supports two channels, that I could simply utilize a mixer or that ALSA would automatically support sending and receiving monaural data to/from my stereo-only driver. Ultimately, I wasn't able to make it work. Is this a mode of operation that ALSA supports, or does ALSA require the driver to support single-channel operation in order to send/receive monaural data?
So, I decided that I should support both mono and stereo in the driver. It appears that ALSA looks at the minimum period size and decides to send that much audio data for playback. The minimum period size is in bytes, which means that the number of mono and stereo frames per period will differ. This introduces a bit of additional unwanted complexity. I'm wondering if there is a way for ALSA to support a fixed number of frames per period. I see that there is a bit field SNDRV_PCM_INFO_FIFO_IN_FRAMES, and a fifo_size h/w parameter, but I'm not sure how this relates to the period size.
I feel like this is a common mode of operation (fixed number of frames per period, regardless of the number of channels), and that it's likely supported by ALSA, but I don't know how it's supposed to work. Should I set up a rule to alter the minimum period size, based on the number of channels?
Best Regards, Paul Stone
Paul Stone wrote:
I thought that simply by reporting that my driver only supports two channels, that I could simply utilize a mixer or that ALSA would automatically support sending and receiving monaural data to/from my stereo-only driver. Ultimately, I wasn't able to make it work. Is this a mode of operation that ALSA supports, or does ALSA require the driver to support single-channel operation in order to send/receive monaural data?
The driver should report only those sample formats that the hardware actually supports.
The ALSA library can do automatic sample rate/format conversions (with the "default" or "plughw" devices). However, this does not work if you bypass it with the "hw" device.
It appears that ALSA looks at the minimum period size and decides to send that much audio data for playback.
No; it tells you how large the buffer is, and your driver programs the hardware to play from that buffer. The application is responsible for keeping the buffer filled.
Periods are where your hardware raises interrupts, to report progress.
The minimum period size is in bytes
The fields in the snd_pcm_hw structure are for commonly-used constraints. But you can put other constraints on the period size, if you need to.
But do you actually need it? (Does your hardware support mono?)
Regards, Clemens
participants (2)
-
Clemens Ladisch
-
Paul Stone