GNU bug report logs - #74863
31.0.50; Problems with play-sound on MS-Windows

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74863 in the body.
You can then email your comments to 74863 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Problems with play-sound on MS-Windows
Date: Sat, 14 Dec 2024 00:50:34 +0100

There are some problems with play-sound, but I didn't find an active bug 
for them. Before working on them I have a couple of questions:

- Is sound playing synchronous on purpose?

- To support :data, we can use the PlaySound function, but we will lose
the ability to play files other than wav. We can maintain the current 
code for files, and use PlaySound for :data. Another option would be to 
simply save data to a temp file and play the file.

Message #8 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sat, 14 Dec 2024 10:42:08 +0200

> Date: Sat, 14 Dec 2024 00:50:34 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> There are some problems with play-sound, but I didn't find an active bug 
> for them. Before working on them I have a couple of questions:
> 
> - Is sound playing synchronous on purpose?

It's synchronous because AFAIK the equivalent features on GNU/Linux
play sound synchronously.  We have a policy of not installing features
that might put non-free systems at an advantage.  So we can make the
sound playing on Windows asynchronous (which is very easily done on
Windows) once there is such a capability on free systems.

> - To support :data, we can use the PlaySound function, but we will lose
> the ability to play files other than wav. We can maintain the current 
> code for files, and use PlaySound for :data. Another option would be to 
> simply save data to a temp file and play the file.

I'd say the former is preferable, but without losing the ability to
play the files we can today.  That is, maintain the current code for
files and add new code for :data.

Thanks.

Message #11 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sat, 14 Dec 2024 15:07:39 +0100

On 14/12/2024 9:42, Eli Zaretskii wrote:
>> - Is sound playing synchronous on purpose?
> 
> It's synchronous because AFAIK the equivalent features on GNU/Linux
> play sound synchronously.  We have a policy of not installing features
> that might put non-free systems at an advantage.  So we can make the
> sound playing on Windows asynchronous (which is very easily done on
> Windows) once there is such a capability on free systems.

Should we add support for PipeWire on GNU/Linux?

Message #14 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sat, 14 Dec 2024 16:56:17 +0200

> Date: Sat, 14 Dec 2024 15:07:39 +0100
> Cc: 74863 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 14/12/2024 9:42, Eli Zaretskii wrote:
> >> - Is sound playing synchronous on purpose?
> > 
> > It's synchronous because AFAIK the equivalent features on GNU/Linux
> > play sound synchronously.  We have a policy of not installing features
> > that might put non-free systems at an advantage.  So we can make the
> > sound playing on Windows asynchronous (which is very easily done on
> > Windows) once there is such a capability on free systems.
> 
> Should we add support for PipeWire on GNU/Linux?

I don't know what PipeWire is, so I have no opinion on this.

Message #17 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 01:35:46 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Should we add support for PipeWire on GNU/Linux?

ALSA clients can be configured to output via PipeWire, and the Pipewire
project itself recommends staying with the ALSA API, at least for now:

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-audio-api-do-you-recommend-to-use

> I don't know what PipeWire is, so I have no opinion on this.

It's a new multimedia server that replaces both Pulse Audio and JACK.
AFAIK, it's the default sound server on Debian when using Gnome, and on
Fedora 34.

Message #20 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 12:55:35 +0100

[Message part 1 (text/plain, inline)]

On 14/12/2024 9:42, Eli Zaretskii wrote:
>> - To support :data, we can use the PlaySound function, but we will lose
>> the ability to play files other than wav. We can maintain the current
>> code for files, and use PlaySound for :data. Another option would be to
>> simply save data to a temp file and play the file.
> 
> I'd say the former is preferable, but without losing the ability to
> play the files we can today.  That is, maintain the current code for
> files and add new code for :data.

This patch adds support for :data using PlaySound, keeping the current 
code for files.

It also fixes a problem in the handling of the volume. Let me know if I 
have to make a separate patch/bug.

Tested with mingw64 and mingw32.

To test:

(defun load-file-into-unibyte-string (file-path)
  (with-temp-buffer
    (set-buffer-multibyte nil)
    (insert-file-contents file-path)
    (buffer-string)))

(play-sound `(sound :data ,(load-file-into-unibyte-string "awav.wav") 
:volume 100))

(play-sound '(sound :file "awav.wav" :volume 100))

[0001-Add-support-for-the-data-keyword-for-play-sound-in-M.patch (text/plain, attachment)]

Message #23 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 14:50:11 +0200

> Date: Sun, 15 Dec 2024 12:55:35 +0100
> Cc: 74863 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> This patch adds support for :data using PlaySound, keeping the current 
> code for files.

Thanks.

> It also fixes a problem in the handling of the volume. Let me know if I 
> have to make a separate patch/bug.

No need.

> To test:
> 
> (defun load-file-into-unibyte-string (file-path)
>    (with-temp-buffer
>      (set-buffer-multibyte nil)
>      (insert-file-contents file-path)
>      (buffer-string)))
> 
> (play-sound `(sound :data ,(load-file-into-unibyte-string "awav.wav") 
> :volume 100))

What's wrong with insert-file-contents-literally?

> +  if (in_memory)
> +    i_result = !PlaySound (psz_file_or_data, NULL, SND_MEMORY);

AFAIU, the documentation seems to say that the string passed as the
first argument to PlaySound is limited to 256 characters (i.e. bytes)?
If so, how do we play longer sounds?

Should we also use SND_SENTRY flag (on Vista and later)?

Message #26 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 19:33:35 +0100

[Message part 1 (text/plain, inline)]

On 15/12/2024 13:50, Eli Zaretskii wrote:

>> (defun load-file-into-unibyte-string (file-path)
>>     (with-temp-buffer
>>       (set-buffer-multibyte nil)
>>       (insert-file-contents file-path)
>>       (buffer-string)))
>>
>> (play-sound `(sound :data ,(load-file-into-unibyte-string "awav.wav")
>> :volume 100))
> 
> What's wrong with insert-file-contents-literally?

Nothing. So many functions...

> 
>> +  if (in_memory)
>> +    i_result = !PlaySound (psz_file_or_data, NULL, SND_MEMORY);
> 
> AFAIU, the documentation seems to say that the string passed as the
> first argument to PlaySound is limited to 256 characters (i.e. bytes)?
> If so, how do we play longer sounds?

I think this limitation applies only when the argument points to a 
string, and not when using SND_MEMORY, which is documented with: "The 
pszSound parameter points to a sound loaded in memory."

It's true the documentation doesn't say so, and I haven't found any 
clarification by Microsoft, but SND_MEMORY would be useless otherwise. 
Also I see normal usage searching the internet.

> Should we also use SND_SENTRY flag (on Vista and later)?

Yes, done in the attached patch.

[0001-Add-support-for-the-data-keyword-for-play-sound-in-M.patch (text/plain, attachment)]

Message #29 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 20:48:59 +0200

> Date: Sun, 15 Dec 2024 19:33:35 +0100
> Cc: 74863 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> >> +  if (in_memory)
> >> +    i_result = !PlaySound (psz_file_or_data, NULL, SND_MEMORY);
> > 
> > AFAIU, the documentation seems to say that the string passed as the
> > first argument to PlaySound is limited to 256 characters (i.e. bytes)?
> > If so, how do we play longer sounds?
> 
> I think this limitation applies only when the argument points to a 
> string, and not when using SND_MEMORY, which is documented with: "The 
> pszSound parameter points to a sound loaded in memory."
> 
> It's true the documentation doesn't say so, and I haven't found any 
> clarification by Microsoft, but SND_MEMORY would be useless otherwise. 
> Also I see normal usage searching the internet.

So there are no limitations whatsoever on the length of that string?

Message #32 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 21:36:03 +0100

On 15/12/2024 2:35, Stefan Kangas wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> Should we add support for PipeWire on GNU/Linux?
> 
> ALSA clients can be configured to output via PipeWire, and the Pipewire
> project itself recommends staying with the ALSA API, at least for now:
> 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-audio-api-do-you-recommend-to-use
> 
>> I don't know what PipeWire is, so I have no opinion on this.
> 
> It's a new multimedia server that replaces both Pulse Audio and JACK.
> AFAIK, it's the default sound server on Debian when using Gnome, and on
> Fedora 34.

Thank you.

I expected this to be easier to make async, but will try with alsa.

Message #35 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 21:38:23 +0100

On 15/12/2024 19:48, Eli Zaretskii wrote:
>> Date: Sun, 15 Dec 2024 19:33:35 +0100
>> Cc: 74863 <at> debbugs.gnu.org
>> From: Cecilio Pardo <cpardo <at> imayhem.com>
>>
>>>> +  if (in_memory)
>>>> +    i_result = !PlaySound (psz_file_or_data, NULL, SND_MEMORY);
>>>
>>> AFAIU, the documentation seems to say that the string passed as the
>>> first argument to PlaySound is limited to 256 characters (i.e. bytes)?
>>> If so, how do we play longer sounds?
>>
>> I think this limitation applies only when the argument points to a
>> string, and not when using SND_MEMORY, which is documented with: "The
>> pszSound parameter points to a sound loaded in memory."
>>
>> It's true the documentation doesn't say so, and I haven't found any
>> clarification by Microsoft, but SND_MEMORY would be useless otherwise.
>> Also I see normal usage searching the internet.
> 
> So there are no limitations whatsoever on the length of that string?

Everything (except the documentation) points to that.

Message #38 received at 74863 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Cecilio Pardo <cpardo <at> imayhem.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 74863 <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sun, 15 Dec 2024 22:16:24 +0000

Cecilio Pardo <cpardo <at> imayhem.com> writes:

> On 15/12/2024 2:35, Stefan Kangas wrote:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> Should we add support for PipeWire on GNU/Linux?
>>
>> ALSA clients can be configured to output via PipeWire, and the Pipewire
>> project itself recommends staying with the ALSA API, at least for now:
>>
>> https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-audio-api-do-you-recommend-to-use
>>
>>> I don't know what PipeWire is, so I have no opinion on this.
>>
>> It's a new multimedia server that replaces both Pulse Audio and JACK.
>> AFAIK, it's the default sound server on Debian when using Gnome, and on
>> Fedora 34.
>
> Thank you.
>
> I expected this to be easier to make async, but will try with alsa.

Thanks for working on this.

Message #43 received at 74863-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 74863-done <at> debbugs.gnu.org
Subject: Re: bug#74863: 31.0.50; Problems with play-sound on MS-Windows
Date: Sat, 21 Dec 2024 12:37:37 +0200

> Date: Sun, 15 Dec 2024 19:33:35 +0100
> Cc: 74863 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 15/12/2024 13:50, Eli Zaretskii wrote:
> 
> >> (defun load-file-into-unibyte-string (file-path)
> >>     (with-temp-buffer
> >>       (set-buffer-multibyte nil)
> >>       (insert-file-contents file-path)
> >>       (buffer-string)))
> >>
> >> (play-sound `(sound :data ,(load-file-into-unibyte-string "awav.wav")
> >> :volume 100))
> > 
> > What's wrong with insert-file-contents-literally?
> 
> Nothing. So many functions...
> 
> > 
> >> +  if (in_memory)
> >> +    i_result = !PlaySound (psz_file_or_data, NULL, SND_MEMORY);
> > 
> > AFAIU, the documentation seems to say that the string passed as the
> > first argument to PlaySound is limited to 256 characters (i.e. bytes)?
> > If so, how do we play longer sounds?
> 
> I think this limitation applies only when the argument points to a 
> string, and not when using SND_MEMORY, which is documented with: "The 
> pszSound parameter points to a sound loaded in memory."
> 
> It's true the documentation doesn't say so, and I haven't found any 
> clarification by Microsoft, but SND_MEMORY would be useless otherwise. 
> Also I see normal usage searching the internet.
> 
> > Should we also use SND_SENTRY flag (on Vista and later)?
> 
> Yes, done in the attached patch.

Thanks, installed on master, and closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.