[Alsaplayer-devel] libalsaplayer in LiVES

[Hubert Chan]

There are two ways of interacting with AlsaPlayer.  One way is through 
libalsaplayer, and requires you to start alsaplayer as a separate 
process -- in your case probably using the daemon interface.  The 
second way is by creating an interface plugin (but I think that would 
less appropriate for your case).

You can take a look at my LIRC AlsaPlayer control program 
<http://www.uhoreg.ca/programming/ap-lirc.text> as an example of using 
libalsaplayer.  Versions 0.3 and prior used libalsaplayer; versions 
0.4 and later used an interface plugin.  (You probably shouldn't use 
the "system" function to run alsaplayer like I did, though.  Do a 
proper fork and exec instead.)  Since you don't know if the user has 
an already-running alsaplayer session, and it would be rude to hijack 
their session, you should probably start alsaplayer with the --session 
and/or --session-name options, and use the ap_find_session(...) and/or 
ap_session_running(...) functions in libalsaplayer.

By creating an interface plugin, you can integrate much more closely 
with AlsaPlayer, but in this case, AlsaPlayer runs as the main 
program, and your interface is loaded by AlsaPlayer, which is probably 
not what you want.  However, this could be used to get around any 
limitations in libalsaplayer, by creating an interface plugin that 
just provides LiVES with a way of communicating with it.  For example, 
I think it would be handy to have an XMPP/XML-RPC/SOAP/D-BUS/... 
interface plugin for AlsaPlayer.  But this may be too much work than 
what you want.

Salsaman wrote:
> What I would like is:
> 
> - play the audio in same/separate thread

Alsaplayer would actually be running as a separate process, but that 
shouldn't make too much of a difference.  Just make sure to call 
ap_quit(...) when LiVES terminates, to clean up the alsaplayer 
process.  One problem, though, is that if LiVES crashes or otherwise 
terminates abnormally, there will be an Alsaplayer process sticking 
around.

> - realtime control of the audio, so that when the video clip is 
> switched, the 
> audio track (file) is also switched

I don't know if there's much latency between when an libalsaplayer 
function is called, and when it actually happens, so there may be some 
sync issues.  You'll have to try that out.

> - ability to pause the audio
> - ability to change the audio speed in realtime, including reverse 
> play
> - ability to adjust the volume in realtime

These are easily done.

> - ability to take timing from the sound card, so that video and audio 
> remain 
> in sync
> - knowing when the audio seek is ready, so that video and audio 
> playback can 
> begin simultaneously

Not sure about these.

> - ability to capture any audio that is being sent to the soundcard 
> (record 
> mode)

I don't think that AlsaPlayer can record, but you can write an input 
plugin.  And you could write an output plugin that writes to a file.  
But that may be too much work.

> - ability to let the user pick the audio devices for playback and 
> capture

I don't think you can change the audio device of an already-running 
alsaplayer session.  But you can always quit alsaplayer, and then 
restart it with the appropriate "-o" argument.

HTH

-- 
Hubert Chan <hubert at uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.