play-sound-file & esd

play-sound-file & esd

[Sam Steingold]

GNU Emacs 22.0.50.22 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2006-04-25 on quant8

when esd is running, play-sound-file fails:

Debugger entered--Lisp error: (error "/dev/dsp: Device or resource busy")
  play-sound-internal((sound :file "/usr/share/sounds/error.wav"))
  play-sound((sound :file "/usr/share/sounds/error.wav"))
  play-sound-file("/usr/share/sounds/error.wav")
  eval((play-sound-file "/usr/share/sounds/error.wav"))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)

is there a workaround?

thanks.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://www.dhimmi.com http://www.mideasttruth.com http://ffii.org
http://truepeace.org http://www.palestinefacts.org
To a Lisp hacker, XML is S-expressions with extra cruft.

Re: play-sound-file & esd

[Sam Steingold]

> * Sam Steingold <fqf@cbqiny.bet> [2006-04-25 15:43:57 -0400]:
>
> GNU Emacs 22.0.50.22 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2006-04-25 on quant8
>
> when esd is running, play-sound-file fails:
>
> Debugger entered--Lisp error: (error "/dev/dsp: Device or resource busy")
>   play-sound-internal((sound :file "/usr/share/sounds/error.wav"))
>   play-sound((sound :file "/usr/share/sounds/error.wav"))
>   play-sound-file("/usr/share/sounds/error.wav")
>   eval((play-sound-file "/usr/share/sounds/error.wav"))
>   eval-last-sexp-1(nil)
>   eval-last-sexp(nil)
>   call-interactively(eval-last-sexp)
>
> is there a workaround?

C-] runs the command abort-recursive-edit ==>

Program received signal SIGSEGV, Segmentation fault.
0x00000020 in ?? ()
(gdb) where
#0  0x00000020 in ?? ()
#1  0x081869bb in sound_cleanup (arg=137529545) at sound.c:458
#2  0x0814d14d in unbind_to (count=32, value=137529545) at eval.c:3258
#3  0x0814d769 in unwind_to_catch (catch=0xbfd97dfc, value=Variable "value" is n
ot available.
) at eval.c:1257
#4  0x0814f4c3 in Fsignal (error_symbol=137574209, data=137529545)
    at eval.c:1690
#5  0x080f379b in recursive_edit_1 () at keyboard.c:1002
#6  0x080f3827 in Frecursive_edit () at keyboard.c:1061
#7  0x0814f0a3 in Ffuncall (nargs=1, args=0xbfd96d60) at eval.c:2899
#8  0x08179d4f in Fbyte_code (bytestr=180328899, vector=179581212, maxdepth=32)
    at bytecode.c:694
#9  0x0814e641 in Feval (form=176921173) at eval.c:2248
#10 0x0814ea2f in Fprogn (args=175009413) at eval.c:433
#11 0x0808d77e in Fsave_window_excursion (args=175009413) at window.c:6418
#12 0x08178fd6 in Fbyte_code (bytestr=180329107, vector=180370236, 
    maxdepth=224) at bytecode.c:855
#13 0x0814ec08 in funcall_lambda (fun=177132300, nargs=2, 
    arg_vector=0xbfd97014) at eval.c:3089
#14 0x0814f007 in Ffuncall (nargs=3, args=0xbfd97010) at eval.c:2957
#15 0x0815076a in Fapply (nargs=2, args=0xbfd97060) at eval.c:2394
#16 0x08150874 in apply1 (fn=137756433, arg=190868541) at eval.c:2658
#17 0x0814df83 in call_debugger (arg=190868541) at eval.c:290
#18 0x0814e0eb in find_handler_clause (handlers=137574185, conditions=Variable "
conditions" is not available.
)
---Type <return> to continue, or q <return> to quit---
    at eval.c:1838
#19 0x0814f4eb in Fsignal (error_symbol=137574185, data=190868565)
    at eval.c:1665
#20 0x0814fa87 in error (m=0x81a769f "%s: %s", a1=0x81ae2b7 "/dev/dsp", 
    a2=0x218338 "Device or resource busy", a3=0x0) at eval.c:1922
#21 0x08186a88 in sound_perror (msg=0x81ae2b7 "/dev/dsp") at sound.c:327
#22 0x08186e0d in Fplay_sound_internal (sound=190868597) at sound.c:1066
#23 0x0814f0b3 in Ffuncall (nargs=2, args=0xbfd975a0) at eval.c:2902
#24 0x08179d4f in Fbyte_code (bytestr=136119955, vector=136119988, maxdepth=16)
    at bytecode.c:694
#25 0x0814ec08 in funcall_lambda (fun=136119916, nargs=1, 
    arg_vector=0xbfd976c4) at eval.c:3089
#26 0x0814f007 in Ffuncall (nargs=2, args=0xbfd976c0) at eval.c:2957
#27 0x08179d4f in Fbyte_code (bytestr=136564243, vector=136564300, maxdepth=32)
    at bytecode.c:694
#28 0x0814ec08 in funcall_lambda (fun=136564180, nargs=1, 
    arg_vector=0xbfd97780) at eval.c:3089
#29 0x0814edce in apply_lambda (fun=136564180, args=190868621, eval_flag=1)
    at eval.c:3011
#30 0x0814e50b in Feval (form=190868629) at eval.c:2300
#31 0x0814f0b3 in Ffuncall (nargs=2, args=0xbfd978b0) at eval.c:2902
#32 0x08179d4f in Fbyte_code (bytestr=137025875, vector=137026052, maxdepth=64)
    at bytecode.c:694
---Type <return> to continue, or q <return> to quit---
#33 0x0814ec08 in funcall_lambda (fun=137025836, nargs=1, 
    arg_vector=0xbfd979e4) at eval.c:3089
#34 0x0814f007 in Ffuncall (nargs=2, args=0xbfd979e0) at eval.c:2957
#35 0x08179d4f in Fbyte_code (bytestr=137026707, vector=137026764, maxdepth=32)
    at bytecode.c:694
#36 0x0814ec08 in funcall_lambda (fun=137026668, nargs=1, 
    arg_vector=0xbfd97b74) at eval.c:3089
#37 0x0814f007 in Ffuncall (nargs=2, args=0xbfd97b70) at eval.c:2957
#38 0x0814c42a in Fcall_interactively (function=137986537, 
    record_flag=137529545, keys=137570044) at callint.c:884
#39 0x080edcb3 in Fcommand_execute (cmd=137986537, record_flag=137529545, 
    keys=137529545, special=137529545) at keyboard.c:9760
#40 0x080f8f4b in command_loop_1 () at keyboard.c:1791
#41 0x0814dc02 in internal_condition_case (bfun=0x80f8bd0 <command_loop_1>, 
    handlers=137574185, hfun=0x80f39c0 <cmd_error>) at eval.c:1474
#42 0x080f2c63 in command_loop_2 () at keyboard.c:1328
#43 0x0814dcba in internal_catch (tag=137570417, 
    func=0x80f2c40 <command_loop_2>, arg=137529545) at eval.c:1212
#44 0x080f367c in command_loop () at keyboard.c:1307
#45 0x080f372a in recursive_edit_1 () at keyboard.c:1000
#46 0x080f3827 in Frecursive_edit () at keyboard.c:1061
#47 0x080e9e95 in main (argc=1, argv=0xbfd98464) at emacs.c:1789
(gdb) up
#1  0x081869bb in sound_cleanup (arg=137529545) at sound.c:458
458             current_sound_device->close (current_sound_device);
(gdb) list
453          Lisp_Object arg;
454     {
455       if (current_sound_device)
456         {
457           if (current_sound_device->close)
458             current_sound_device->close (current_sound_device);
459           if (current_sound->fd > 0)
460             emacs_close (current_sound->fd);
461         }
462
(gdb) p current_sound_device
$1 = (struct sound_device *) 0xbfd95720
(gdb) p *current_sound_device
$2 = {file = 0x136002f <Address 0x136002f out of bounds>, fd = -1076274512, 
  format = -1076275240, volume = 2463836, sample_size = 159696204, 
  sample_rate = -1076274464, bps = 8, channels = 2298200, 
  open = 0x164720 <_int_free+14>, close = 0x20, 
  configure = 0x231130 <main_arena+16>, choose_format = 0xb71d770, 
  write = 0xb85818, data = 0xbfd95ae0}
(gdb) up
#2  0x0814d14d in unbind_to (count=32, value=137529545) at eval.c:3258
3258            (*this_binding.func) (this_binding.old_value);
(gdb) p this_binding
No symbol "this_binding" in current context.
(gdb) list
3253
3254          struct specbinding this_binding;
3255          this_binding = *--specpdl_ptr;
3256
3257          if (this_binding.func != 0)
3258            (*this_binding.func) (this_binding.old_value);
3259          /* If the symbol is a list, it is really (SYMBOL WHERE
3260             . CURRENT-BUFFER) where WHERE is either nil, a buffer, or a
3261             frame.  If WHERE is a buffer or frame, this indicates we
3262             bound a variable that had a buffer-local or frame-local
(gdb) p specpdl_ptr
$3 = (struct specbinding *) 0x9a04f80
(gdb) p *specpdl_ptr
$4 = {symbol = 137529545, old_value = 137529545, 
  func = 0x81869a0 <sound_cleanup>, unused = 0}
(gdb) xsymbol specpdl_ptr->symbol
Attempt to take address of value not located in memory.
(gdb) c
Continuing.
Fatal error (11)
Program received signal SIGSEGV, Segmentation fault.
0x00471402 in __kernel_vsyscall ()
(gdb) where
#0  0x00471402 in __kernel_vsyscall ()
#1  0x00129546 in kill () from /lib/libc.so.6
#2  0x080eaaab in fatal_error_signal (sig=11) at emacs.c:430
#3  <signal handler called>
#4  0x00000020 in ?? ()
#5  0x081869bb in sound_cleanup (arg=137529545) at sound.c:458
#6  0x0814d14d in unbind_to (count=32, value=137529545) at eval.c:3258
#7  0x0814d769 in unwind_to_catch (catch=0xbfd97dfc, value=Variable "value" is not available.
) at eval.c:1257
#8  0x0814f4c3 in Fsignal (error_symbol=137574209, data=137529545)
    at eval.c:1690
#9  0x080f379b in recursive_edit_1 () at keyboard.c:1002
#10 0x080f3827 in Frecursive_edit () at keyboard.c:1061
#11 0x0814f0a3 in Ffuncall (nargs=1, args=0xbfd96d60) at eval.c:2899
#12 0x08179d4f in Fbyte_code (bytestr=180328899, vector=179581212, maxdepth=32)
    at bytecode.c:694
#13 0x0814e641 in Feval (form=176921173) at eval.c:2248
#14 0x0814ea2f in Fprogn (args=175009413) at eval.c:433
#15 0x0808d77e in Fsave_window_excursion (args=175009413) at window.c:6418
#16 0x08178fd6 in Fbyte_code (bytestr=180329107, vector=180370236, 
    maxdepth=224) at bytecode.c:855
#17 0x0814ec08 in funcall_lambda (fun=177132300, nargs=2, 
    arg_vector=0xbfd97014) at eval.c:3089
#18 0x0814f007 in Ffuncall (nargs=3, args=0xbfd97010) at eval.c:2957
---Type <return> to continue, or q <return> to quit---
#19 0x0815076a in Fapply (nargs=2, args=0xbfd97060) at eval.c:2394
#20 0x08150874 in apply1 (fn=137756433, arg=190868541) at eval.c:2658
#21 0x0814df83 in call_debugger (arg=190868541) at eval.c:290
#22 0x0814e0eb in find_handler_clause (handlers=137574185, conditions=Variable "conditions" is not available.
)
    at eval.c:1838
#23 0x0814f4eb in Fsignal (error_symbol=137574185, data=190868565)
    at eval.c:1665
#24 0x0814fa87 in error (m=0x81a769f "%s: %s", a1=0x81ae2b7 "/dev/dsp", 
    a2=0x218338 "Device or resource busy", a3=0x0) at eval.c:1922
#25 0x08186a88 in sound_perror (msg=0x81ae2b7 "/dev/dsp") at sound.c:327
#26 0x08186e0d in Fplay_sound_internal (sound=190868597) at sound.c:1066
#27 0x0814f0b3 in Ffuncall (nargs=2, args=0xbfd975a0) at eval.c:2902
#28 0x08179d4f in Fbyte_code (bytestr=136119955, vector=136119988, maxdepth=16)
    at bytecode.c:694
#29 0x0814ec08 in funcall_lambda (fun=136119916, nargs=1, 
    arg_vector=0xbfd976c4) at eval.c:3089
#30 0x0814f007 in Ffuncall (nargs=2, args=0xbfd976c0) at eval.c:2957
#31 0x08179d4f in Fbyte_code (bytestr=136564243, vector=136564300, maxdepth=32)
    at bytecode.c:694
#32 0x0814ec08 in funcall_lambda (fun=136564180, nargs=1, 
    arg_vector=0xbfd97780) at eval.c:3089
#33 0x0814edce in apply_lambda (fun=136564180, args=190868621, eval_flag=1)
    at eval.c:3011
---Type <return> to continue, or q <return> to quit---
#34 0x0814e50b in Feval (form=190868629) at eval.c:2300
#35 0x0814f0b3 in Ffuncall (nargs=2, args=0xbfd978b0) at eval.c:2902
#36 0x08179d4f in Fbyte_code (bytestr=137025875, vector=137026052, maxdepth=64)
    at bytecode.c:694
#37 0x0814ec08 in funcall_lambda (fun=137025836, nargs=1, 
    arg_vector=0xbfd979e4) at eval.c:3089
#38 0x0814f007 in Ffuncall (nargs=2, args=0xbfd979e0) at eval.c:2957
#39 0x08179d4f in Fbyte_code (bytestr=137026707, vector=137026764, maxdepth=32)
    at bytecode.c:694
#40 0x0814ec08 in funcall_lambda (fun=137026668, nargs=1, 
    arg_vector=0xbfd97b74) at eval.c:3089
#41 0x0814f007 in Ffuncall (nargs=2, args=0xbfd97b70) at eval.c:2957
#42 0x0814c42a in Fcall_interactively (function=137986537, 
    record_flag=137529545, keys=137570044) at callint.c:884
#43 0x080edcb3 in Fcommand_execute (cmd=137986537, record_flag=137529545, 
    keys=137529545, special=137529545) at keyboard.c:9760
#44 0x080f8f4b in command_loop_1 () at keyboard.c:1791
#45 0x0814dc02 in internal_condition_case (bfun=0x80f8bd0 <command_loop_1>, 
    handlers=137574185, hfun=0x80f39c0 <cmd_error>) at eval.c:1474
#46 0x080f2c63 in command_loop_2 () at keyboard.c:1328
#47 0x0814dcba in internal_catch (tag=137570417, 
    func=0x80f2c40 <command_loop_2>, arg=137529545) at eval.c:1212
#48 0x080f367c in command_loop () at keyboard.c:1307
---Type <return> to continue, or q <return> to quit---
#49 0x080f372a in recursive_edit_1 () at keyboard.c:1000
#50 0x080f3827 in Frecursive_edit () at keyboard.c:1061
#51 0x080e9e95 in main (argc=1, argv=0xbfd98464) at emacs.c:1789

Lisp Backtrace:
"recursive-edit"
"byte-code"
"debug"
"play-sound-internal"
"play-sound"
"play-sound-file"
"eval"
"eval-last-sexp-1"
"eval-last-sexp"
"call-interactively"
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://jihadwatch.org http://camera.org http://memri.org http://ffii.org
http://truepeace.org http://palestinefacts.org http://thereligionofpeace.com
People with a good taste are especially appreciated by cannibals.

Re: play-sound-file & esd

[Richard Stallman]

Does this fix it?  It compiles, but I have not tested it
(I am not sure how).

*** sound.c	07 Feb 2006 18:13:40 -0500	1.34
--- sound.c	28 Apr 2006 19:47:17 -0400	
***************
*** 452,464 ****
  sound_cleanup (arg)
       Lisp_Object arg;
  {
!   if (current_sound_device)
!     {
!       if (current_sound_device->close)
! 	current_sound_device->close (current_sound_device);
!       if (current_sound->fd > 0)
! 	emacs_close (current_sound->fd);
!     }
  
    return Qnil;
  }
--- 452,463 ----
  sound_cleanup (arg)
       Lisp_Object arg;
  {
!   if (current_sound_device->close)
!     current_sound_device->close (current_sound_device);
!   if (current_sound->fd > 0)
!     emacs_close (current_sound->fd);
!   free (current_sound_device);
!   free (current_sound);
  
    return Qnil;
  }
***************
*** 991,998 ****
  #ifndef WINDOWSNT
    Lisp_Object file;
    struct gcpro gcpro1, gcpro2;
-   struct sound_device sd;
-   struct sound s;
    Lisp_Object args[2];
  #else /* WINDOWSNT */
    int len = 0;
--- 990,995 ----
***************
*** 1010,1057 ****
  #ifndef WINDOWSNT
    file = Qnil;
    GCPRO2 (sound, file);
!   bzero (&sd, sizeof sd);
!   bzero (&s, sizeof s);
!   current_sound_device = &sd;
!   current_sound = &s;
    record_unwind_protect (sound_cleanup, Qnil);
!   s.header = (char *) alloca (MAX_SOUND_HEADER_BYTES);
  
    if (STRINGP (attrs[SOUND_FILE]))
      {
        /* Open the sound file.  */
!       s.fd = openp (Fcons (Vdata_directory, Qnil),
! 		    attrs[SOUND_FILE], Qnil, &file, Qnil);
!       if (s.fd < 0)
  	sound_perror ("Could not open sound file");
  
        /* Read the first bytes from the file.  */
!       s.header_size = emacs_read (s.fd, s.header, MAX_SOUND_HEADER_BYTES);
!       if (s.header_size < 0)
  	sound_perror ("Invalid sound file header");
      }
    else
      {
!       s.data = attrs[SOUND_DATA];
!       s.header_size = min (MAX_SOUND_HEADER_BYTES, SBYTES (s.data));
!       bcopy (SDATA (s.data), s.header, s.header_size);
      }
  
    /* Find out the type of sound.  Give up if we can't tell.  */
!   find_sound_type (&s);
  
    /* Set up a device.  */
    if (STRINGP (attrs[SOUND_DEVICE]))
      {
        int len = SCHARS (attrs[SOUND_DEVICE]);
!       sd.file = (char *) alloca (len + 1);
!       strcpy (sd.file, SDATA (attrs[SOUND_DEVICE]));
      }
  
    if (INTEGERP (attrs[SOUND_VOLUME]))
!     sd.volume = XFASTINT (attrs[SOUND_VOLUME]);
    else if (FLOATP (attrs[SOUND_VOLUME]))
!     sd.volume = XFLOAT_DATA (attrs[SOUND_VOLUME]) * 100;
  
    args[0] = Qplay_sound_functions;
    args[1] = sound;
--- 1007,1056 ----
  #ifndef WINDOWSNT
    file = Qnil;
    GCPRO2 (sound, file);
!   current_sound_device = (struct sound_device *) xmalloc (sizeof (struct sound_device));
!   bzero (current_sound_device, sizeof (struct sound_device));
!   current_sound = (struct sound *) xmalloc (sizeof (struct sound));
!   bzero (current_sound, sizeof (struct sound));
    record_unwind_protect (sound_cleanup, Qnil);
!   current_sound->header = (char *) alloca (MAX_SOUND_HEADER_BYTES);
  
    if (STRINGP (attrs[SOUND_FILE]))
      {
        /* Open the sound file.  */
!       current_sound->fd = openp (Fcons (Vdata_directory, Qnil),
! 				 attrs[SOUND_FILE], Qnil, &file, Qnil);
!       if (current_sound->fd < 0)
  	sound_perror ("Could not open sound file");
  
        /* Read the first bytes from the file.  */
!       current_sound->header_size
! 	= emacs_read (current_sound->fd, current_sound->header,
! 		      MAX_SOUND_HEADER_BYTES);
!       if (current_sound->header_size < 0)
  	sound_perror ("Invalid sound file header");
      }
    else
      {
!       current_sound->data = attrs[SOUND_DATA];
!       current_sound->header_size = min (MAX_SOUND_HEADER_BYTES, SBYTES (current_sound->data));
!       bcopy (SDATA (current_sound->data), current_sound->header, current_sound->header_size);
      }
  
    /* Find out the type of sound.  Give up if we can't tell.  */
!   find_sound_type (current_sound);
  
    /* Set up a device.  */
    if (STRINGP (attrs[SOUND_DEVICE]))
      {
        int len = SCHARS (attrs[SOUND_DEVICE]);
!       current_sound_device->file = (char *) alloca (len + 1);
!       strcpy (current_sound_device->file, SDATA (attrs[SOUND_DEVICE]));
      }
  
    if (INTEGERP (attrs[SOUND_VOLUME]))
!     current_sound_device->volume = XFASTINT (attrs[SOUND_VOLUME]);
    else if (FLOATP (attrs[SOUND_VOLUME]))
!     current_sound_device->volume = XFLOAT_DATA (attrs[SOUND_VOLUME]) * 100;
  
    args[0] = Qplay_sound_functions;
    args[1] = sound;
***************
*** 1060,1086 ****
    /* There is only one type of device we currently support, the VOX
       sound driver.  Set up the device interface functions for that
       device.  */
!   vox_init (&sd);
  
    /* Open the device.  */
!   sd.open (&sd);
  
    /* Play the sound.  */
!   s.play (&s, &sd);
! 
!   /* Close the input file, if any.  */
!   if (!STRINGP (s.data))
!     {
!       emacs_close (s.fd);
!       s.fd = -1;
!     }
! 
!   /* Close the device.  */
!   sd.close (&sd);
  
    /* Clean up.  */
-   current_sound_device = NULL;
-   current_sound = NULL;
    UNGCPRO;
  
  #else /* WINDOWSNT */
--- 1059,1073 ----
    /* There is only one type of device we currently support, the VOX
       sound driver.  Set up the device interface functions for that
       device.  */
!   vox_init (current_sound_device);
  
    /* Open the device.  */
!   current_sound_device->open (current_sound_device);
  
    /* Play the sound.  */
!   current_sound->play (current_sound, current_sound_device);
  
    /* Clean up.  */
    UNGCPRO;
  
  #else /* WINDOWSNT */

Re: play-sound-file & esd

[Richard Stallman]

    when esd is running, play-sound-file fails:

I think what is needed is to make play-sound-file work with esd.
Can you find out the specs for communicating with esd?

Re: play-sound-file & esd

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2006-04-28 23:50:23 -0400]:
>
>     when esd is running, play-sound-file fails:
>
> I think what is needed is to make play-sound-file work with esd.
> Can you find out the specs for communicating with esd?

package esound-devel on fc5 contains
        /usr/include/esd.h
and
        /usr/share/aclocal/esd.m4

No, I do not volunteer for this task.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://camera.org http://memri.org http://dhimmi.com
http://honestreporting.com http://palestinefacts.org
MS: our tomorrow's software will run on your tomorrow's HW at today's speed.

Re: play-sound-file & esd

[Jan Djärv]

Sam Steingold skrev:
>> * Richard Stallman <ezf@tah.bet> [2006-04-28 23:50:23 -0400]:
>>
>>     when esd is running, play-sound-file fails:
>>
>> I think what is needed is to make play-sound-file work with esd.
>> Can you find out the specs for communicating with esd?
> 
> package esound-devel on fc5 contains
>         /usr/include/esd.h
> and
>         /usr/share/aclocal/esd.m4
> 
> No, I do not volunteer for this task.
> 

It does not fail for me with Fedora Core 5.  Are you using ALSA drivers, if 
not, can you try with them instead?  Also, I seem to recall that esd will be 
replaced with GStreamer in the future, so making Emacs use esd may not be 
worth the effort.

	Jan D.

Re: play-sound-file & esd

[Richard Stallman]

      Also, I seem to recall that esd will be 
    replaced with GStreamer in the future, so making Emacs use esd may not be 
    worth the effort.

How near in the future?

Re: play-sound-file & esd

[Jan Djärv]

Richard Stallman skrev:
>       Also, I seem to recall that esd will be 
>     replaced with GStreamer in the future, so making Emacs use esd may not be 
>     worth the effort.
> 
> How near in the future?

I guess that is like knowing the answer to "When will Emacs 22.0 be released?" 
:-).  Seriously though, I don't follow Gnome development that much.  But the 
developer documents already says you should use GStreamer for multimedia 
(http://developer.gnome.org/doc/guides/platform-overview/platform-overview.html#multimedia).

It may be that esd will be kept for older apps and GStreamer plays sound 
through esd.

Another issue is the sound drivers in the kernel.  The old OSS drivers does 
not allow more than one open to the sound device, but the newer ALSA drivers 
do.  The new ALSA drivers are default in the Linux kernel now, so the original 
problem does not occur if you are using ALSA drivers.

Then there is the workaround to run emacs through esddsp:

% esddsp emacs

I don't have the original problem on my machine (I have ALSA drivers) so I 
don't know if it solves the original problem, but it should.

If we still are going to play sound with esd, may I suggest just execing 
esdplay with the file name?

	Jan D.

Re: play-sound-file & esd

[David Hansen]

On Wed, 03 May 2006 08:48:56 +0200 Jan Djärv wrote:

> Another issue is the sound drivers in the kernel.  The old
> OSS drivers does not allow more than one open to the sound
> device, but the newer ALSA drivers do.  The new ALSA drivers
> are default in the Linux kernel now, so the original problem
> does not occur if you are using ALSA drivers.

But only if your Soundcard has a hardware mixer (as most
cheap on board chips don't have).  Or do i have to enable
this feature explicitly in my kernel config?

David

Re: play-sound-file & esd

[Andreas Schwab]

David Hansen <david.hansen@gmx.net> writes:

> On Wed, 03 May 2006 08:48:56 +0200 Jan Djärv wrote:
>
>> Another issue is the sound drivers in the kernel.  The old
>> OSS drivers does not allow more than one open to the sound
>> device, but the newer ALSA drivers do.  The new ALSA drivers
>> are default in the Linux kernel now, so the original problem
>> does not occur if you are using ALSA drivers.
>
> But only if your Soundcard has a hardware mixer (as most
> cheap on board chips don't have).  Or do i have to enable
> this feature explicitly in my kernel config?

The current ALSA library implements a software mixer.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: play-sound-file & esd

[Richard Stallman]

    Another issue is the sound drivers in the kernel.  The old OSS drivers does 
    not allow more than one open to the sound device, but the newer ALSA drivers 
    do.  The new ALSA drivers are default in the Linux kernel now, so the original 
    problem does not occur if you are using ALSA drivers.

In that case, I think we don't NEED to do anything.

In the future, we might still want to make Emacs talk to esd or to
GStreamer.  If GStreamer will work thru esd, it would be better for
Emacs to use esd.  Is esd used only in GNOME?  Are there other contexts
that use esd but not GStreamer?

    If we still are going to play sound with esd, may I suggest just execing 
    esdplay with the file name?

If such a simple method does the job, it is fine with me.

Re: play-sound-file & esd

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2006-05-03 16:42:58 -0400]:
>
>     If we still are going to play sound with esd, may I suggest just
>     execing esdplay with the file name?
>
> If such a simple method does the job, it is fine with me.

if esd just happens not to be running at the moment, then esdplay will
just hang.  i.e., before running esdplay, one has to ensure that esd is
up and running (and is in a workable state).

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://pmw.org.il http://honestreporting.com http://memri.org
http://ffii.org http://dhimmi.com http://jihadwatch.org http://camera.org
Those who beat their swords into plowshares plow for those who do not.

Re: play-sound-file & esd

[Richard Stallman]

    if esd just happens not to be running at the moment, then esdplay will
    just hang.  i.e., before running esdplay, one has to ensure that esd is
    up and running (and is in a workable state).

I don't recall if we ever reached a firm conclusion about whether
Emacs needs to know how to talk to esd.  Some argued that, with recent
ALSA, Emacs should work fine without knowing about esd.
Is that a clear consensus?

Re: play-sound-file & esd

[Jan Djärv]

Richard Stallman skrev:
>     if esd just happens not to be running at the moment, then esdplay will
>     just hang.  i.e., before running esdplay, one has to ensure that esd is
>     up and running (and is in a workable state).
> 
> I don't recall if we ever reached a firm conclusion about whether
> Emacs needs to know how to talk to esd.  Some argued that, with recent
> ALSA, Emacs should work fine without knowing about esd.
> Is that a clear consensus?

I only know that ALSA drivers allows multiple opens of the sound device, and 
for a similar problem regarding Realplayer and esd the suggested solution it 
to switch to ALSA drivers.  But Sam must himself confirm that it indeed solves 
his problem.

	Jan D.

Re: play-sound-file & esd

[Richard Stallman]

    I only know that ALSA drivers allows multiple opens of the sound device, and 
    for a similar problem regarding Realplayer and esd the suggested solution it 
    to switch to ALSA drivers.  But Sam must himself confirm that it indeed solves 
    his problem.

Sam, can you try this and report?

Re: play-sound-file & esd

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2006-05-08 18:29:27 -0400]:
>
>     I only know that ALSA drivers allows multiple opens of the sound
>     device, and for a similar problem regarding Realplayer and esd the
>     suggested solution it to switch to ALSA drivers.  But Sam must
>     himself confirm that it indeed solves his problem.
>
> Sam, can you try this and report?

I use a vanilla fc5. I think it already uses alsa (it has alsa-lib and
alsa-utils 1.0.11 installed).

I work around the problem by running esd with "-as 2" argument: after 2
seconds of inactivity it releases the sound devices, so if esd programs
are not running, then emacs can play sounds.

if I use esdplayer to play a sound and call play-sound-file in emacs at
the same time, I get an error in emacs.


-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://truepeace.org http://jihadwatch.org http://ffii.org
http://dhimmi.com http://camera.org http://mideasttruth.com http://iris.org.il
Bill Gates is not god and Microsoft is not heaven.

Re: play-sound-file & esd

[Richard Stallman]

    I use a vanilla fc5. I think it already uses alsa (it has alsa-lib and
    alsa-utils 1.0.11 installed).

Can someone tell Sam how to make sure of whether it is running
Alsa, and if so, which version?

Re: play-sound-file & esd

[David Hansen]

On Tue, 09 May 2006 16:41:19 -0400 Richard Stallman wrote:

>     I use a vanilla fc5. I think it already uses alsa (it has alsa-lib and
>     alsa-utils 1.0.11 installed).
>
> Can someone tell Sam how to make sure of whether it is running
> Alsa, and if so, which version?

Make sure the volume is low and

$ cat /dev/urandom >  /dev/audio

You should here the nice sound of urandom.  This means the
alsa drivers are working.

To make the software mixer work i also had to write a
/etc/asound.conf (i just c&p the example from
http://www.pseudorandom.co.uk/2004/debian/alsa/).

Now just start some apps that use alsa as the audio output
device e.g.:

$ ogg123 -q -d alsa09 Tom_Waits_-_01_-_Tom_Trauberts_Blues.ogg &

is working for me.

BTW ogg123 uses libao to play sounds and the user can decide
himself which device / sound daemon is used.  Maybe worth to
think about that option.

To get the version number...  I don't know.  On my debian
system i have libasound2 installed, apt-cache says it has
version 1.0.11-3 and pkg-config --version asound says 0.20.

And thanks to the guy who pointed out that GNU/Linux finally
has a software mixer in the kernel.

David

Re: play-sound-file & esd

[Jan Djärv]

David Hansen skrev:

> To get the version number...  I don't know.  On my debian
> system i have libasound2 installed, apt-cache says it has
> version 1.0.11-3 and pkg-config --version asound says 0.20.

% cat /proc/asound/version

If you don't have that file you are not using ALSA.

	Jan D.

Re: play-sound-file & esd

[Sam Steingold]

> * Jan Djärv <wna.u.q@fjvcarg.fr> [2006-05-10 08:26:32 +0200]:
>
> David Hansen skrev:
>
>> To get the version number...  I don't know.  On my debian
>> system i have libasound2 installed, apt-cache says it has
>> version 1.0.11-3 and pkg-config --version asound says 0.20.
>
> % cat /proc/asound/version
>
> If you don't have that file you are not using ALSA.

$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).


-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://honestreporting.com http://thereligionofpeace.com http://truepeace.org
http://openvotingconsortium.org http://pmw.org.il http://ffii.org
Parachute for sale, used once, never opened, small stain.

Re: play-sound-file & esd

[Jan Djärv]

Sam Steingold skrev:

>> % cat /proc/asound/version
>> 
>> If you don't have that file you are not using ALSA.
> 
> $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version
> 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
> 

Hmm, maybe your card isn't supported well by ALSA.  What dou you have for
% cat /proc/asound/oss/sndstat
and
% cat /proc/asound/cards

?

You should see your card as device 0 in cards, and there should be a line 
saying "ALSA emulation" in the first.

	Jan D.

Re: play-sound-file & esd

[Sam Steingold]

> * Jan Djärv <wna.u.q@fjvcarg.fr> [2006-05-10 15:17:16 +0200]:
>
> Sam Steingold skrev:
>
>>> % cat /proc/asound/version
>>>
>>> If you don't have that file you are not using ALSA.
>>
>> $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version
>> 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
>>
>
> Hmm, maybe your card isn't supported well by ALSA.  What dou you have for
> % cat /proc/asound/oss/sndstat

$ cat /proc/asound/oss/sndstat
Sound Driver:3.8.1a-980706 (ALSA v1.0.11rc2 emulation code)
Kernel: Linux quant8 2.6.16-1.2096_FC5 #1 Wed Apr 19 05:15:21 EDT 2006 i686
Config options: 0

Installed drivers:
Type 10: ALSA emulation

Card config:
Intel 82801DB-ICH4 with AD1981B at 0xfeb00400, irq 18

Audio devices:
0: Intel 82801DB-ICH4 (DUPLEX)

Synth devices: NOT ENABLED IN CONFIG

Midi devices: NOT ENABLED IN CONFIG

Timers:
31: system timer

Mixers:
0: Analog Devices AD1981B


> and
> % cat /proc/asound/cards

$ cat /proc/asound/cards
 0 [I82801DBICH4   ]: ICH4 - Intel 82801DB-ICH4
                      Intel 82801DB-ICH4 with AD1981B at 0xfeb00400, irq 18


let me repeat the problem description:

when esd is not running (or when it was started with "-as 2" and has not
been used for 2 sec), emacs play-sound-file works fine.
when esd is running, esdplay also works fine.

but when esd _is_ running, emacs play-sound-file fails with


Debugger entered--Lisp error: (error "/dev/dsp: Device or resource busy")
  play-sound-internal((sound :file "/usr/share/sounds/error.wav"))
  play-sound((sound :file "/usr/share/sounds/error.wav"))
  play-sound-file("/usr/share/sounds/error.wav")
  eval((play-sound-file "/usr/share/sounds/error.wav"))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)



-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://openvotingconsortium.org http://pmw.org.il http://memri.org
http://dhimmi.com http://palestinefacts.org http://jihadwatch.org
Whom computers would destroy, they must first drive mad.

Re: play-sound-file & esd

[Richard Stallman]

Where do we stand on this?

It looks like you are running ALSA v1.0.11rc2, and it does NOT
work to have multiple opens.  ALSA experts, is that version supposed
to be new enough to support multiple opens?

Re: play-sound-file & esd

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> Where do we stand on this?
>
> It looks like you are running ALSA v1.0.11rc2, and it does NOT
> work to have multiple opens.  ALSA experts, is that version supposed
> to be new enough to support multiple opens?

AFAIK that version should be new enough.  But only the native ALSA
interface has access to the software mixer.  When using the legacy OSS
interface (eg. through /dev/dsp) you are still limited to a single open.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: play-sound-file & esd

[Jan Djärv]

Andreas Schwab skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>> Where do we stand on this?
>>
>> It looks like you are running ALSA v1.0.11rc2, and it does NOT
>> work to have multiple opens.  ALSA experts, is that version supposed
>> to be new enough to support multiple opens?
> 
> AFAIK that version should be new enough.  But only the native ALSA
> interface has access to the software mixer.  When using the legacy OSS
> interface (eg. through /dev/dsp) you are still limited to a single open.
> 

Aha, that is why it works for me.  So then we should make Emacs use the ALSA 
API.  This doesn't look too hard, but I guess it is something for after the 
release.

	Jan D.

Re: play-sound-file & esd

[Richard Stallman]

    AFAIK that version should be new enough.  But only the native ALSA
    interface has access to the software mixer.  When using the legacy OSS
    interface (eg. through /dev/dsp) you are still limited to a single open.

So, what does that imply for Emacs?  Does Emacs use it through the
native ALSA interface or through a "legacy interface"?

Re: play-sound-file & esd

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     AFAIK that version should be new enough.  But only the native ALSA
>     interface has access to the software mixer.  When using the legacy OSS
>     interface (eg. through /dev/dsp) you are still limited to a single open.
>
> So, what does that imply for Emacs?  Does Emacs use it through the
> native ALSA interface or through a "legacy interface"?

Emacs does not use the ALSA API.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: play-sound-file & esd

[Richard Stallman]

    Aha, that is why it works for me.  So then we should make Emacs use the ALSA 
    API.  This doesn't look too hard, but I guess it is something for after the 
    release.

This is a bug, so we should fix it now if we can.

Re: play-sound-file & esd

[joakim]

Jan Djärv <jan.h.d@swipnet.se> writes:

Just some notes:

- Alsa enables multiopen only if the underlying hardware supports
  this. Cheap laptop audio normally doesnt for instance.
- There are several sound daemons out there: 
  - esd used by gnome
  - arts used by kde
  - gstreamer
  - jackd used by people interested in music applications
  
I would say that finding a solution for emacs that always manages to
play a sound withouth configuration is next to impossible.

Maybe a solution would be to make it possible to configure an external
player command, when the internal method is not suficient?



> Andreas Schwab skrev:
>> Richard Stallman <rms@gnu.org> writes:
>> 
>>> Where do we stand on this?
>>>
>>> It looks like you are running ALSA v1.0.11rc2, and it does NOT
>>> work to have multiple opens.  ALSA experts, is that version supposed
>>> to be new enough to support multiple opens?
>> AFAIK that version should be new enough.  But only the native ALSA
>> interface has access to the software mixer.  When using the legacy OSS
>> interface (eg. through /dev/dsp) you are still limited to a single open.
>> 
>
> Aha, that is why it works for me.  So then we should make Emacs use
> the ALSA API.  This doesn't look too hard, but I guess it is something
> for after the release.
>
> 	Jan D.

-- 
Joakim Verona
http://www.verona.se

Re: play-sound-file & esd

[Andreas Schwab]

joakim@verona.se writes:

> Jan Djärv <jan.h.d@swipnet.se> writes:
>
> Just some notes:
>
> - Alsa enables multiopen only if the underlying hardware supports
>   this.

That's not true any more for the latest ALSA version, which now includes a
software mixer.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: play-sound-file & esd

[Richard Stallman]

    - There are several sound daemons out there: 
      - esd used by gnome
      - arts used by kde
      - gstreamer

    I would say that finding a solution for emacs that always manages to
    play a sound withouth configuration is next to impossible.

I'm not sure what "without configuration" means in this case.
Do you mean, a single method that works in all cases?
We don't need it to be one single method; Emacs is configured for
many aspects of the system, and there's no harm in having more.

    Maybe a solution would be to make it possible to configure an external
    player command, when the internal method is not suficient?

If that works, it is good.  For instance, if working thru esd can be
done conveniently by forking an external program, that would be an ok
implementation.

What about arts and gstreamer?  Can they be used by fork/exec too?

      - jackd used by people interested in music applications

It sounds like that one is less common and thus less important to
support.  However, if it too can be supported by forking an external
program, that would be nice.  Can it be?


However, given that ALSA now includes a software mixer capability,
implementing direct communication with ALSA is also a good solution.
Probably better, since it would work with esd, arts, gstreamer, and
jackd, without having to know about them.  It would also be much more
efficient.

Re: play-sound-file & esd

[Richard Stallman]

    That's not true any more for the latest ALSA version, which now includes a
    software mixer.

What is the version number that has this?

Re: play-sound-file & esd

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2006-05-17 16:07:51 -0400]:
>
>     Maybe a solution would be to make it possible to configure an external
>     player command, when the internal method is not suficient?
>
> If that works, it is good.  For instance, if working thru esd can be
> done conveniently by forking an external program, that would be an ok
> implementation.

we are going in circles.
I already said before (in http://article.gmane.org/gmane.emacs.devel:53961):

if esd just happens not to be running at the moment, then esdplay will
just hang.  i.e., before running esdplay, one has to ensure that esd is
up and running (and is in a workable state).



-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://ffii.org http://honestreporting.com http://iris.org.il http://pmw.org.il
http://jihadwatch.org http://palestinefacts.org http://truepeace.org
Can I do it in Lisp, or would you rather wait an extra couple of months?

Re: play-sound-file & esd

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     That's not true any more for the latest ALSA version, which now includes a
>     software mixer.
>
> What is the version number that has this?

I don't know the exact version, but AFAIK it was added beween 1.0.9 and
1.0.11.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: play-sound-file & esd

[Jan D.]

Richard Stallman wrote:
>     Aha, that is why it works for me.  So then we should make Emacs use the ALSA 
>     API.  This doesn't look too hard, but I guess it is something for after the 
>     release.
> 
> This is a bug, so we should fix it now if we can.

I've checked in alsa support in sound.c.  The code first tries alsa and 
if that fails, the old vox driver is used.

	Jan D.

Re: play-sound-file & esd

[Jan Djärv]

Andreas Schwab skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>>     That's not true any more for the latest ALSA version, which now includes a
>>     software mixer.
>>
>> What is the version number that has this?
> 
> I don't know the exact version, but AFAIK it was added beween 1.0.9 and
> 1.0.11.
> 

In the code I checked in, I just require 1.0.0.

	Jan D.

Re: play-sound-file & esd

[Richard Stallman]

    I don't know the exact version, but AFAIK it was added beween 1.0.9 and
    1.0.11.

Then how come Sam experienced that multiple opens don't fail?
He is using version 1.0.11.

Re: play-sound-file & esd

[Richard Stallman]

    >     Maybe a solution would be to make it possible to configure an external
    >     player command, when the internal method is not suficient?
    >
    > If that works, it is good.  For instance, if working thru esd can be
    > done conveniently by forking an external program, that would be an ok
    > implementation.

    we are going in circles.

No we aren't.

    I already said before (in http://article.gmane.org/gmane.emacs.devel:53961):

    if esd just happens not to be running at the moment, then esdplay will
    just hang.  i.e., before running esdplay, one has to ensure that esd is
    up and running (and is in a workable state).

That is true, but it does not conflict with what I said.  Using
esdplay could be an ok implementation for how to make Emacs output to
esd.

Of course, outputting to esd (by any method) will only work when esd
is running.  So this can't be the whole solution, only part of one.
Emacs would have to know the method to output to each of the various
sound demons, and know how to decide which method to use.

The point is that implementing several methods could be easy if they
can all work by running external programs such as (for example)
esdplay.

That still would leave the question of how to decide which method to
use.  I don't know how hard that is.

Outputting directly to ALSA could also be a good solution.  That would
have to be implemented at C level as far as I know.

And we have to get to the bottom of the anomaly that you are running
ALSA 1.0.11, which supposedly has a software mixer, but your
observation is that it does not allow multi-open.

Re: play-sound-file & esd

[Jan Djärv]

Richard Stallman skrev:

> 
> And we have to get to the bottom of the anomaly that you are running
> ALSA 1.0.11, which supposedly has a software mixer, but your
> observation is that it does not allow multi-open.
> 

I think Andreas may have answered that, if you open the old sound device 
(/dev/dsp) you don't get multi-open.  You must use the ALSA API for this.  But 
it sounds odd for esd to not use ALSA with such a recent version of esd.

The result of a test with the new ALSA implementation in Emacs would be 
interesting.

	Jan D.

Re: play-sound-file & esd

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     I don't know the exact version, but AFAIK it was added beween 1.0.9 and
>     1.0.11.
>
> Then how come Sam experienced that multiple opens don't fail?
> He is using version 1.0.11.

I hope I'm answering the right question here, but I recall that the
alsa oss layer will permit multiple opens of the /dev/dsp device, if
the underlying hardare supports it. I also asked on #lad to verify
this. The alsa software mixer wont be available to oss devices,
though.

This is also consistent with what I experience with my hardware.

- on my laptop, with sad audio hardware, I always have to kill esd or
artsd in order to work with music applications, since these use jackd.

- on my workstation with a somewhat better audi card, this isnt
  necessary because the audio daemons just use another hardware
  channel than the music audio daemon jackd.

I hope I didnt add to the confusion.

-- 
Joakim Verona
http://www.verona.se

Re: play-sound-file & esd

[Richard Stallman]

Thank you very much.

Re: play-sound-file & esd

[Burton Samograd]

joakim@verona.se writes:

> Jan Djärv <jan.h.d@swipnet.se> 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.

-- 
burton samograd					kruhft .at. gmail
kruhft.blogspot.com	www.myspace.com/kruhft	metashell.blogspot.com

Re: play-sound-file & esd

[Jan Djärv]

Burton Samograd skrev:
> joakim@verona.se writes:
> 
>> Jan Djärv <jan.h.d@swipnet.se> 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.

    Jan D.

Re: play-sound-file & esd

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Burton Samograd skrev:
>> joakim@verona.se writes:
>>
>>> Jan Djärv <jan.h.d@swipnet.se> 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

Re: play-sound-file & esd

[Jan Djärv]

> 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.

Re: play-sound-file & esd

[Richard Stallman]

Jan recently wrote the code to talk directly to ALSA, so I think
there is no need any more to work on other methods.

Re: play-sound-file & esd

[Richard Stallman]

    > I just wrote some code for my jabber client to play sounds
    > asynchronously

I didn't notice the word "asynchronously" when I responded before.
Sorry.

    I guess we need to add async sound playing in the future.  But then you have 
    to add a cancel-sound as well.

This might be useful to do in the future, after the release.  I don't
think that having a cancel-sound function is a high cost.

David Kastrup wrote:

    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 agree.

    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

I think we won't really need (a) if we have (b).

Re: play-sound-file & esd

[Romain Francoise]

"Jan D." <jan.h.d@swipnet.se> writes:

> I've checked in alsa support in sound.c.  The code first tries alsa
> and if that fails, the old vox driver is used.

On which hardware did you test it?

On my main machine (Intel i810 chipset, Linux 2.6.16.14) I get:

| play-sound: Unable to get buffer size for playback: Invalid argument

On another machine (SB Live!, Linux 2.4.22), I get:

| play-sound: Unable to get period size for playback: Invalid argument

In both cases using libasound2 version 1.0.11; in both cases playing
sounds with ``alsaplayer -o alsa'' works.

Thanks,

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: play-sound-file & esd

[Jan D.]

Romain Francoise wrote:
> "Jan D." <jan.h.d@swipnet.se> writes:
>
>   
>> I've checked in alsa support in sound.c.  The code first tries alsa
>> and if that fails, the old vox driver is used.
>>     
>
> On which hardware did you test it?
>   

All I got, which is some older Soundblasters and some AC97:s.
> On my main machine (Intel i810 chipset, Linux 2.6.16.14) I get:
>
> | play-sound: Unable to get buffer size for playback: Invalid argument
>
> On another machine (SB Live!, Linux 2.4.22), I get:
>
> | play-sound: Unable to get period size for playback: Invalid argument
>
> In both cases using libasound2 version 1.0.11; in both cases playing
> sounds with ``alsaplayer -o alsa'' works.
>
>   

Can you send me the sound file and the output from aplay -v <file>?

Thanks,

    Jan D.

Re: play-sound-file & esd

[Jan Djärv]

Romain Francoise writes:
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
>> Can you send me the sound file and the output from aplay -v <file>?
> 
> The file is attached, and aplay -v shows:
> 

Thanks, I know what the problem is.  I've made a change, can you try it?  The 
hardware I have doesn't trigger this bug.

Thanks,

	Jan D.

Re: play-sound-file & esd

[Romain Francoise]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I've made a change, can you try it?  The hardware I have doesn't
> trigger this bug.

It works fine now, thanks,

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter