[alsa-devel] ALSA C++ API
Takashi Iwai
tiwai at suse.de
Wed Sep 19 14:25:43 CEST 2007
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
More information about the Alsa-devel
mailing list