[PD] [PD-dev] audio apis

[Jonathan Wilkes]

________________________________
>From: Roman Haefeli <reduzent at gmail.com>
>To: pd-list at iem.at 
>Sent: Thursday, May 23, 2013 9:21 AM
>Subject: Re: [PD] [PD-dev] audio apis


>On Die, 2013-05-21 at 12:47 +0200, Patrice Colet wrote:
>> > 7) Does anyone using GNU/Linux system want to use pulse-audio with
>> > Pd?  The main reason would be easy software mixing-- for example,
>> > you could watch a tutorial on youtube and get sound out of a running
>> > instance of Pd without doing any configuration whatsoever.  (At
>> > least that's what Pulse Audio claims-- I haven't used it so much.)
>> >
>> 
>>  It's hard to stay polite about this, for me it has never worked
>> correctly,
>> the best way to have sound always going out from audiocard on
>> linux/ubuntu is about removing pulse-audio,
>> since ever, everytime.

> It's hard not to get political about this, but for me pulseaudio has
> always worked as expected and it basically freed me of hassling around
> with Linux audio issues. The only hassle about it are softwares like Pd
> that prevent it from working silently by not supporting it.


Ok, after some extensive communication on the pulseaudio irc chatroom of
freenode, here's what I've come up with:

1) One could technically change the ALSA device list in the audio dialog
and put a special entry in the list for "default", and on the ALSA backend
just set the device name to "default".  On a machine running PulseAudio
this would hand the audio to Pulse, which means you'd get software mixing
without any additional setup.  Unfortunately, because of the way Pd's ALSA
backend works with mmap the output is pretty much crap (lots of dropouts)
so it's not a solution unless someone does more extensive revision of

s_audio_alsa.c.  (I don't entirely understand the mmap stuff myself.)


2) Pulse's claim of "drop-in replacement for Esound" is from the perspective

of a prospective GNU/Linux distribution-- in other words, _if_ the distro wants
to configure Pulse with Esound support, then everything that used Esound
_should_ work with Pulse.  However, that support is optional-- extant distros
may or may not have that configuration.  Thus client software cannot rely on
its own Esound backend to work on a distro with Pulse out of the box, so
even if s_audio_esd.c is a working backend it would give spotty coverage.
(And I was pretty much guided away from going that route on the irc chat.)

3) The consensus for Pulse support was clearly "build a Pulse backend."
I can safely say that one benefit of doing so would be that new users would
get audio input/output that "just works" for casual/beginner patching-- e.g.,
watching a tutorial on the web while patching in Pd.  (I focus on beginners
not because veteran users don't browse the web while patching, but because
veteran users probably already know how to route through Jack to get
web audio and Pd audio to play at the same time.)


Beyond that software mixing it's hard to say what the benefits would be.
Not because I don't think PulseAudio has benefits, but because
s_audio_alsa.c isn't the greatest ALSA backend ever written so it's
impossible to gauge the reliability of Pulse by trying #1 above.  I can
say that everyone on the PulseAudio list was extremely helpful in trying
to get software mixing in Pd without having to write a whole Pulse backend.
(Especially considering I don't really understand the ALSA API  nor the Pulse
one all that well.)


So it's a bit of a pickle-- a new user can already most likely get audio
output from Pd right away, and someone who wants extremely
low latency has exactly zero need for Pulse being in the mix at all.  So the
only real use case I see is mixing with the audio from the rest of the system.
That's important, but it's unclear to me whether it necessitates the work it
would take to create and test an additional audio backend.


Anyway I'd love to hear from people who have more knowledge about
audio backends/servers than I do.  I really was only working on integrating Pd's
audio dialog GUI into a Preferences dialog and fell down this Linux Audio Hell
Rabbit Hole...

Best,
Jonathan



> I know, everyone mileage varies.

>Roman




_______________________________________________
Pd-list at iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list