Making sound from Perl - How?

agraham agraham at g-b.net
Wed May 30 11:45:48 UTC 2012


On 05/30/2012 09:58 AM, Michael Schwendt wrote:
> On Tue, 29 May 2012 22:12:45 +0100, agraham wrote:
>
>> Hi Guys,
>>
>> Are there any perl bindings in Fedora to play sound samples from perl?
>>
>> e.g. The ability to use PortAudio or Libao or something else from perl?
>
> A bit of background could have been helpful. Have you searched for specific
> packages? Do you know specific Perl modules that could be available in
> Fedora, too? (e.g. after researching them at CPAN?)
>
> Both
>    yum search perl audio
> and
>    yum search perl sound
>
> don't find anything obvious. But I know that "perl-SDL" is available
> in Fedora. It just doesn't show up in a basic package search because
> its package description is very brief and doesn't expand on what "SDL"
> offers.
>

WARNING - LONG REPLY AHEAD
==========================

My application requires that I send raw sound samples (in various 
formats) in real-time with low latency, so that excludes all file format 
type "players" from the search.

 From what I see on CPAN, this leaves:

1. Audio::Ao - an interface to the libao library
2. Libao-perl - another interface to libao
3. Audio::PortAudio - an interface to PortAudio
4. Audio::ESD - an interface into Esound
4. SDL Sound..

My application is SDL based and it needs to run on Fedora 14 >, but 
perl-SDL does not exist on F14 and the version that exists on FC17 is 
v2.2-6 which is too old for me I need 2.5x.

So, I've back ported the entire perl-SDL stack and dependencies and 
built RPMs and that do run on F14 > :).

What I've tried so far:

SDL Sound
=========
SDL sound only plays files, there is a means of sending sound samples, 
via a callback, but that is badly broken at the moment and has other 
issues which I won't go into as a result of these issues I've had to 
find another solution.

Audio::Ao
=========
Audio::Ao is an interface to libao and works on x64, but it segfaults on 
i686, I'm currently investigating this bug.

Another problem with Audio::Ao/Libao  is PulseAudio prevents you using 
libao via its official documented interface!

As an example, install vorbis-tools (to get ogg123) and play an ogg file:

Audio Device:   PulseAudio Output
Playing: file.ogg
Ogg Vorbis stream: 2 channel, 44100 Hz

ERROR: Cannot open device pulse. <-----

Now if you specify the device as ASLA it works,

ogg123 -d alsa file.ogg

The libao interface detects pulse is installed and tries to use it as 
the default device, but pulse does not let it for whatever reason, if 
you tell libao to use ALSA, pulse indirectly works (using virtual ALSA 
device AFAIK) - so PulseAudio is a blocker here, and most likely will 
not be fixed for F14 anyway. - bug report to be filed....

The user cannot be expected to know this when the sound is working via 
pulse in his/her other apps, so ANY app that uses libao with PulseAudio 
installed will most likely fail by default as in the above example.

Libao-perl
==========
The PulseAudio blocker issue also rules out using Libao-perl as its 
doing exactly the same thing as Audio::Ao (if you could get that to 
compile!, which is badly broken).

Audio-ESD and Audio::PortAudio
==============================
So today I've just completed building the RPMs for:

perl-Audio-PortAudio
perl-Audio-ESD

I will test these today in my app. I don't hold any hope for ESD as that 
system is old and not maintained anymore and is very limited in it's 
capability.

PortAudio will "hopefully work" and "hopefully" play nice with 
PulseAudio -- we will see today..

with the exception of SDL, None of the above solutions are part of 
Fedora (any version) and I've had to build everything from  scratch.

There really needs to be more consideration for apps that want to use 
sound, each app has to find it's own solution and re-invent the wheel 
and I have to say I don't know what the solution is, but maybe if 
PulseAudio provided an interface like libao/portaudio that would be a 
good starting point...

It looks like my app is going to have to interface directly with 2 or 3 
sound subsystems to ensure that the user can get sound...

Albert


More information about the users mailing list