http://rafb.net/paste/results/nI811998.html
I have been studying the ALSA driver and lib API, and in doing so have written a simple raw pcm player. I used the tutorials written by Dr Matthias Nagorni and Paul Davis as templates, along with alot of gdb sessions with aplay. It is by no means intended for any real use, its purpose is to be used as a soft 'breadboard' so to speak; a simple tool for dropping functions in, examining hardware, etc. When I feel I'm ready, the next step is to make a callback based version, as per the Davis howto. Ultimately, I wish to "forget all of this" (jack). I'm spending alot of time at the alsa level because I'm interested highly in the device driver api as well as applications.
I was able to get it working very easily on my laptop (ymfpci based) and was feeling pretty sexy at this point. I started adding stuff like a getopt routine (originally i was changing the struct pm values and recompiling over and over), all kinds of info, hw_params_get and test functions, various debugging functions, throwing all kinds of hw_params at it (periods, period size/time buffer size/time, etc), to closely examine the inner workings of the driver, hardware, etc. I was already starting to look into the jack API (which sent me directly to pthreads as a prerequisite). I'm also refreshing my areas of C that were rusty too, whence all the struct and pointer to struct usage (those were weak areas for me). Then I moved to my desktops to find it fail on a few devices: the ice1712 (delta 1010LT and EZ8) and the intel8x0. It works on the ymfpci and the via82xx. I noticed a problem with the output of snd_pcm_hw_params_dump showing RATE: NONE on my program.
aplay's call: snd_pcm_hw_params_set_rate_near(handle, params, &hwparams.rate, 0);
my pcmplay's call:
snd_pcm_hw_params_set_rate_near(pcm_handle, hwparams, &(params->rate), &dir);
Changing arg4 in my program to 0 fixed the problem. Looks like the recent change to this function bit me again. I sent a post a while back about the return value and arg3, looks like arg4(int *dir) has changed as well. Confirmation? Kinda weird that it works on some and not other devices though, that really thru me for a while. Here is the link once again to the inaccurate documentation:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#a58
This email was actually started to ask for help in finding that problem, which I found while writing it. So now on to the questions that I had been developing before I got sidetracked by that bug, if I can remember them all:)
If I understand correctly, a hardware buffer is a chuck of ram in the audio device itself of a fixed size. I think that the author of a device driver defines the max buffer size by referring to the hardware specs of the chip. Is there more to it than this? I ask because first, I can't seem to get a buffersize setting out of a ymfpci 744 of 256K no matter what hw_params I throw at it, anything higher that 64K (65536 bytes) causes a set buffersize error. I doublechecked to make sure I wasn't confusing bytes with frames, and I'm not. . I got that value of 256K from the driver code, show below. I'm also curious about the comment. Again, isn't this a hardware aspect, and not a question of enough or not? Was it perhaps, that the author was guessing due to lack of specs at the time or something?
static snd_pcm_hardware_t snd_ymfpci_playback =
{
.info = (SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_PAUSE |
SNDRV_PCM_INFO_RESUME),
.formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE,
.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000,
.rate_min = 8000,
.rate_max = 48000,
.channels_min = 1,
.channels_max = 2,
.buffer_bytes_max = 256 * 1024, /* FIXME: enough? */
.period_bytes_min = 64,
.period_bytes_max = 256 * 1024, /* FIXME: enough? */
.periods_min = 3,
.periods_max = 1024,
.fifo_size = 0,
};I had lots more, but I think they were all based on confusion about that bug. Guess it's back to the drawing board for now...
-- http://nostar.isa-geek.com/
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
