[Alsaplayer-devel]Re: libalsaplayer API and multiple soundcards...

Andy Lo-A-Foe andy@alsaplayer.org
Thu, 6 Jun 2002 23:57:58 +0200


Hi Brian!

(CC to alsaplayer-devel, since this is probably useful to others too.
Hope you don't mind)

On Thu, Jun 06, 2002 at 04:39:57PM -0500, Brian M. Rzycki wrote:

> First, I want to thank you for such an excellent audio player.  I was
> truly amazed with the pitch control of mp3s and ogg files.  In fact, I'm
> building a digital mixing device with alsa as the software player.  

Cool! Let me know when you have something we can show off :-)

> Which leads to my first comment. :)  I was hacking alsaplayer with the
> nifty library api you provided and I noticed there wasn't a way to
> adjust the volume via message passing.  After doing a bit of code
> exploration I notied you had several message types in
> app/ControlSocket.cpp which aren't exported to control.h.  I hacked
> message.c to include volume passing (basically cut and pasted the

I think Evgeny (one of the persons starting to hack on alsaplayer too)
just committed these exact functions to CVS a few days ago. I think
ap_set_volume and ap_get_volume are there, as are functions to set/get the
panning. I would suggest you subscribe to alsaplayer-devel and perhaps
to alsaplayer-commits (higher traffic) to keep track of the latest
developments. The latest and greatest code is of course in CVS, so if
you are actively developing it's quite useful to work off that branch.
All instructions to subscribe/checkout can be found on the webpage. Let
me know if it works...

> ap_get_speed() and ap_set_speed() functions and changed the #define type
> and the "speed" string to "volume").  It worked like a champ.  I was
> wondering if you could add in function interfaces for the rest of the
> cases found in app/ControlSocket.cpp.  Several would be very useful to
> me and the hackibility of alsaplayer in general. :)

Yep, extra functionality is very easy to add to libalsaplayer ;-)

> Second, is there a way to send the audio output to two adapters at once?
>  It didn't seem like there was a clear way to do so.  I'm running ALSA
> and I've read with my SBLive! I can access the front and rear channel as
> discrete output lines with /dev/snd/pcmC0D0#0 and /dev/snd/pcmC0D0#1.
> Barring major hacking of alsaplayer, I didn't see a way to do this.  I'd

I don't think I support this yet. However, you can start 2 alsaplayer
processes, one for the front and one for the rear channels. That will
definitely work, as long as you can come up with an alsa device name
(through asoundrc perhaps) that selects these discrete output devices
for you. If this doesn't work I can look into adding direct support for
this in the alsa output plugin. Let me know...

> love to be able to fade between the two adapters with the same audio
> output (for mixing reasons).  Any insight into this would be greatly
> appreciated.  

I think that would require some extra coding, but it should be perfectly
doable with libalsaplayer controlling 2 alsaplayer sessions. I recently
implemented a "daemon" interface plugin (see CVS). Basically this
creates a fully functional player process, but without any graphical
interface. It just sits there waiting for external (libalsaplayer)
commands. You can do something like:

$ alsaplayer -s "alsaplayer-front" -o alsa -d hw:0,0 -i daemon &

$ alsaplayer -s "alsaplayer-rear" -o alsa -d hw:0,1 -i daemon &


(note that hw:0,0 and hw:0,1 are just my guess. You may need another
alsa device name to access both outputs separately)

When both these processes are running you can then get the respective
session_id's by doing an ap_find_session("alsaplayer-front", ...) and
ap_find_session("alsaplayer-rear", ...) call from your program. You will
get 2 session_id's that you can then use to control both daemon
alsaplayers.

> Thanks for a great player!  I've already impressed a few people with
> what little hacking I have done on this pet project.  I guess I should
> go subscribe to dev-alsaplayer...

Definitely! :)

Thanks for the feedback,

Andy