Re: play-sound-file & esd

[David Kastrup]

Jan Djärv <address@hidden> writes:

> Burton Samograd skrev:
>> address@hidden writes:
>>
>>> Jan Djärv <address@hidden> writes:
>>> Maybe a solution would be to make it possible to configure an external
>>> player command, when the internal method is not suficient?
>>
>> I just wrote some code for my jabber client to play sounds
>> asynchronously using an external player app so that I could get event
>> sounds without having my system hang to wait for playback.  I looked
>> at the sound.c code and was trying to figure a quick way for
>> non-blocking playback, but didn't have the time and hacked a elisp
>> version using call-process-shell-command.
>>
>> I can post the code if anyone is interested, but right now it's
>> specific to my demands of playing a different sound on each event; I
>> was planning on ripping it out and sending it to .sources so this
>> could give me the kick to get it done.
>>
>
> I guess we need to add async sound playing in the future.  But then
> you have to add a cancel-sound as well.  Do you have that?  Or one
> could restrict sounds we play to not be longer than a second or two.
> What external command are you using?  I guess one would have to use
> different commands for esd, jack, alsa, oss and so on.

I'd prefer if we could use native interfaces for that.  The main
application I would see for sound within Emacs would be
WYHIWYG-editing of lilypond files and other sound describing programs.
Starting one process for each auditory feedback seems like overkill.
One would rather want to keep a device/socket/pipe open, and ALSA
appears like the most basic access method with a free future: you can
pretty much rely on its presence on current GNU/Linux systems.

I don't think it offers network transparency, but there is no network
transparent variant one could rely on as the main access method,
anyway.

So in order of urgency, one would probably implement:

a) play through a pipe and a command line app started once
b) play through native ALSA

Case a) should cover most systems after being properly configured, as
long as there is some "play" utility that does not get into a tizzy
when pipe underrun occurs.  Changes in sample rate or format would
have to kill and restart the process.

Case b) would be more efficient where ALSA is available.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum