[alsa-devel] basic questions
Hi,
I am ramping up on ALSA architecture and framework. I have a couple of basic questions. I apologize if these questions are very basic to be raised in this mailing list. If anyone can help me find answers, it would be great. Thanks in advance.
1. My assumption is that ALSA handles only PCM streams today. Does it handle encoded streams from application to sound card (Which can do hardware decoding)?
2. What are the hwdep files in ALSA used for? Where do the concerned IOCTLS land to?
Thanks and Regards, Harsha.
On Fri, Mar 14, 2008 at 12:35 AM, Harsha priya gupta harshapriya@gmail.com wrote:
Hi,
I am ramping up on ALSA architecture and framework. I have a couple of basic questions. I apologize if these questions are very basic to be raised in this mailing list. If anyone can help me find answers, it would be great. Thanks in advance.
- My assumption is that ALSA handles only PCM streams today. Does it handle
encoded streams from application to sound card (Which can do hardware decoding)?
Someone else could probably give a better answer, but I believe that currently ALSA has no API for cards that do HW decoding.
- What are the hwdep files in ALSA used for? Where do the concerned IOCTLS
land to?
Anything you want to do that doesn't fit into the ALSA framework. Typically they're used for things like programming the card's DSP engine. I've also used them for testing/QA in embedded development, using hwdep ioctls to provide an alternate playback path, so that any issues can quickly be determined to be an ALSA issue, or a problem with the way we were programming the HW.
See the emu10k1 driver for a good example of hwdep ioctl usage. It's used for things like loading DSP patches.
Lee
On Saturday 15 March 2008 11:35:20 Lee Revell wrote:
On Fri, Mar 14, 2008 at 12:35 AM, Harsha priya gupta
harshapriya@gmail.com wrote:
Hi,
I am ramping up on ALSA architecture and framework. I have a couple of basic questions. I apologize if these questions are very basic to be raised in this mailing list. If anyone can help me find answers, it would be great. Thanks in advance.
- My assumption is that ALSA handles only PCM streams today. Does it
handle encoded streams from application to sound card (Which can do hardware decoding)?
Someone else could probably give a better answer, but I believe that currently ALSA has no API for cards that do HW decoding.
Not AFAIK, and certainly the architecture assumes a constant data rate. I.e X bytes consumed implies elapsed time of (X * constant) = the _period_
Alsa headers do define some format constants for compressed audio.
We would like to support compressed audio for our cards, which can do hardware decoding. I did try to implement it early on, but got lost in the quagmire of driver midlevel code and alsa-lib.
A first step would be to allow CBR compressed formats to pass through to the driver unaltered. For these there is a defined bits per sample, though it can be non-integer which might be a problem.
regards
-- Eliot Blennerhassett www.audioscience.com
On Fri, Mar 14, 2008 at 6:57 PM, Eliot Blennerhassett linux@audioscience.com wrote:
On Saturday 15 March 2008 11:35:20 Lee Revell wrote:
On Fri, Mar 14, 2008 at 12:35 AM, Harsha priya gupta
harshapriya@gmail.com wrote:
Hi,
I am ramping up on ALSA architecture and framework. I have a couple of basic questions. I apologize if these questions are very basic to be raised in this mailing list. If anyone can help me find answers, it would be great. Thanks in advance.
- My assumption is that ALSA handles only PCM streams today. Does it
handle encoded streams from application to sound card (Which can do hardware decoding)?
Someone else could probably give a better answer, but I believe that currently ALSA has no API for cards that do HW decoding.
Not AFAIK, and certainly the architecture assumes a constant data rate. I.e X bytes consumed implies elapsed time of (X * constant) = the _period_
Alsa headers do define some format constants for compressed audio.
We would like to support compressed audio for our cards, which can do hardware decoding. I did try to implement it early on, but got lost in the quagmire of driver midlevel code and alsa-lib.
A first step would be to allow CBR compressed formats to pass through to the driver unaltered. For these there is a defined bits per sample, though it can be non-integer which might be a problem.
I would look at how ALSA implements AC3 passthrough.
Lee
Thanks a lot for the responses.
I see that there can be a way to implement a path for sending encoded streams to sound card driver through ALSA for hardware decoding but it does not explicitly exist today.
There are currently a lot of hardware that support decoding. If there is no existing path in ALSA, what is the recommended way to do so? [ provide different driver for encoded streams?]
As I am new to ALSA, it would be great if anyone could help me quantify the effort and difficulty level involved and provide a direction for the same.
Would I be on the right path if;
1. Like PCM object, register a encoded stream object in ALSA framework 2. Provide IOCTLs from sound card driver for MMF to send encoded buffer 3. (is required??) implement API in ALSA driver and Libasound to route the calls from MMF to sound card IOCTLs
Thanks a lot in advance, -Harsha
On Tue, Mar 18, 2008 at 7:31 AM, Lee Revell rlrevell@joe-job.com wrote:
On Fri, Mar 14, 2008 at 6:57 PM, Eliot Blennerhassett linux@audioscience.com wrote:
On Saturday 15 March 2008 11:35:20 Lee Revell wrote:
On Fri, Mar 14, 2008 at 12:35 AM, Harsha priya gupta
harshapriya@gmail.com wrote:
Hi,
I am ramping up on ALSA architecture and framework. I have a
couple of
basic questions. I apologize if these questions are very basic to
be
raised in this mailing list. If anyone can help me find answers, it
would
be great. Thanks in advance.
- My assumption is that ALSA handles only PCM streams today. Does
it
handle encoded streams from application to sound card (Which can do hardware decoding)?
Someone else could probably give a better answer, but I believe that currently ALSA has no API for cards that do HW decoding.
Not AFAIK, and certainly the architecture assumes a constant data rate.
I.e X
bytes consumed implies elapsed time of (X * constant) = the _period_
Alsa headers do define some format constants for compressed audio.
We would like to support compressed audio for our cards, which can do
hardware
decoding. I did try to implement it early on, but got lost in the
quagmire of
driver midlevel code and alsa-lib.
A first step would be to allow CBR compressed formats to pass through
to the
driver unaltered. For these there is a defined bits per sample, though
it can
be non-integer which might be a problem.
I would look at how ALSA implements AC3 passthrough.
Lee _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (3)
-
Eliot Blennerhassett -
Harsha priya gupta -
Lee Revell