At Tue, 18 Sep 2007 23:19:10 +0300, Lasse Kärkkäinen wrote:
Even though I got no replies to my original announcement, here is a new version that wraps hw and sw params completely, has a macro for checking ALSA C function return values (throws alsa::error) and uses different naming style (similar to the C++ standard library). It is better documented now, too.
The code is now largely generated with macros, so it isn't very readable anymore :/
First, thanks for your work! I had little time to review and comment on it until now.
Honestly speaking, I prefer your former version to this new one. The readability is more important than a bit of performance improvement, especially for such a "wrapper". If we need more performance, we should rewrite it to bypass many redundant C bindings.
How about to put the most of implementation codes to .cc instead of inlining in the header? Also, we don't have to export every alsa-lib functionality. There are many rotten, obsolete and almost internal-only functions.
Next I'll be trying to figure out how the PCM API itself should be wrapped, for C++ style callbacks, etc. I am using the test/pcm.c program for my tests. Does it use good style for error recovery, etc? Mine will base on it, so this is important.
You can use snd_pcm_recover() as a generic solution. It handles both for XRUN and suspend/resume.
Example of use (a port of what test/pcm.c does using a few separate functions and 140 lines of code):
alsa::pcm handle(device); unsigned int rrate = rate; alsa::hw_config(handle) .rate_resample(resample) .set(transfer_methods[method].access) .set(format) .channels(channels) .rate_near(rrate) .buffer_time_near(buffer_time) .get_buffer_size(buffer_size) .period_time_near(period_time) .get_period_size(period_size) .commit(); if (rate != rrate) { std::cout << "Requested rate " << rate << " Hz, got " << rrate << " Hz" << std::endl; rate = rrate; } alsa::sw_config(handle) .start_threshold((buffer_size / period_size) * period_size) .avail_min(period_size) .xfer_align(1) .commit();
I'd prefer to use the Boost libraries (boost::function, boost::noncopyable, etc), but I am afraid that a dependency on them might be problematic. What do you think?
That's true. Boost is often a nightmare for distributions :) But, if it gives more benifits, it might be worth. Do you have a certain idea how will it be?
thanks,
Takashi