From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: play-sound-file & esd Date: Sat, 20 May 2006 14:03:50 +0200 Message-ID: <446F05A6.2000708@swipnet.se> References: <44585258.7040506@swipnet.se> <445EF2F9.5060209@swipnet.se> <87r732wzz6.fsf@robotron.kosmorama> <44618798.3030901@swipnet.se> <4461E7DC.8070007@swipnet.se> <44697D66.5060300@swipnet.se> <87ac9ds7uw.fsf@gmail.com> <446ED886.7090600@swipnet.se> <85r72pf3b7.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1148126724 22802 80.91.229.2 (20 May 2006 12:05:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 20 May 2006 12:05:24 +0000 (UTC) Cc: Burton Samograd , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 20 14:05:22 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FhQCs-0000T4-VF for ged-emacs-devel@m.gmane.org; Sat, 20 May 2006 14:05:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FhQCs-0004FJ-CL for ged-emacs-devel@m.gmane.org; Sat, 20 May 2006 08:05:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FhQBT-0003QA-Bz for emacs-devel@gnu.org; Sat, 20 May 2006 08:03:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FhQBP-0003O8-V4 for emacs-devel@gnu.org; Sat, 20 May 2006 08:03:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FhQBP-0003Np-IX for emacs-devel@gnu.org; Sat, 20 May 2006 08:03:47 -0400 Original-Received: from [81.228.9.186] (helo=av9-2-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FhQEu-0007F3-3h; Sat, 20 May 2006 08:07:24 -0400 Original-Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id E47A0380D7; Sat, 20 May 2006 14:03:42 +0200 (CEST) Original-Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D584D380C9; Sat, 20 May 2006 14:03:42 +0200 (CEST) Original-Received: from coolsville.localdomain (81-235-205-204-no59.tbcn.telia.com [81.235.205.204]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 7E5B537E48; Sat, 20 May 2006 14:03:41 +0200 (CEST) User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) Original-To: David Kastrup In-Reply-To: <85r72pf3b7.fsf@lola.goethe.zz> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54867 Archived-At: > 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. > No, you would need a sound daemon like esd for that. it is a problem that there are so many daemons. I guess one could try to connect to each known sound daemon in order, and if no one is found, use the native method. > 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. > Case b) is what I implemented. Jan D.