Marek Michalak wrote:
> Is there any difference if I write in my code:
> while (size > 0) {
> frames = size;
> err = snd_pcm_mmap_begin(handle, &my_areas, &offset, &frames);
> record_buffor(my_areas, offset, frames, &data->phase);
> snd_pcm_mmap_commit(handle, offset, frames);
> size -= frames;
> }
> OR
> while (rest > 0) {
> size_t c = (rest <= (off64_t)chunk_bytes) ? (size_t)rest :
> chunk_bytes;
> size_t f = c * 8 / bits_per_frame;
> snd_pcm_mmap_readi(audiobuf, f);
> write(fd, audiobuf, c);
> rest -= c;
> }
This depends on what the function record_buffor() does.
snd_pcm_readi() (or the equivalent snd_pcm_mmap_readi() from your second
example) copies data from the sound card's buffer into the user's buffer.
If record_buffor() copies the data elsewhere, too, then there would be
_no_ difference in what the code does.
Using a memory-mapped buffer makes sense only if you actually use the
data in the buffer instead of copying it, i.e., if you make your
computations directly on the data as it is in the buffer.
BTW: Using snd_pcm_mmap_readi() doesn't make much sense if don't also
use snd_pcm_mmap_begin() in your program, because snd_pcm_readi() does
the same but does not require a device that supports mmap.
> I want to have low latency capture and compute fft - is it good way to do
> this?
If your FFT algorithm
* can read the data directly from the sound card buffer,
* does not write to the sound card buffer, and
* can handle the period/buffer layout (which is hardware dependent; not
all sound cards may support your desired period/buffers sizes),
then you can use snd_pcm_mmap_*.
Otherwise, you must use snd_pcm_readi().
Assuming that the FFT needs floating-point numbers, the int-to-float
conversion would be an algorithm that could be easily made to work with
mmap. Or you could write the first step of the FFT so that it reads
integer data from the mmap buffer, converts it to floats, does the
computation, and writes the results to its own processing buffer.
BTW: When capturing, latency depends only on the period size, not on the
buffer size, so you should use as big a buffer as possible to avoid
overruns.
> Is true that snd_async_handler_t *ahandler is better for realtime system
> than nonblocking mode?
No. Asynchronous handlers notify your program with a signal, but you
are not allowed to do anything useful inside the signal handler, so
you'd have to notify your own thread somehow. Using blocking reads or
poll() is more efficient.
Best regards,
Clemens
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user
