From: Daniel Semyonov <daniel@dsemy.com>
To: Richard Stallman <rms@gnu.org>
Cc: iarchivedmywholelife@gmail.com, emacs-devel@gnu.org
Subject: Re: Vendoring code in a (Non?)GNU ELPA package
Date: Wed, 03 Jan 2024 08:20:03 +0200 [thread overview]
Message-ID: <875y0bhrak.fsf@dsemy.com> (raw)
In-Reply-To: <E1rKseg-0003lH-71@fencepost.gnu.org> (Richard Stallman's message of "Tue, 02 Jan 2024 23:14:58 -0500")
>>>>> Richard Stallman writes:
>> My module only uses the audio playback API to play music through
>> Emacs. I don't currently have plans to make use of other parts
>> of the library.
> I see. It woild not be a pronlem to use a simple free linraru for
> that. But maybe it is not necessary. Will `play-sound' do the
> job?
Unfortunately no, for various reasons:
- 'play-sound' blocks Emacs while the sound is playing; the functions my
module implements play audio and manage playback asynchronously.
- 'play-sound' only supports playing WAV and AU files (though I see now
that sound data can also be passed as a string, so I could implement
decoding functions in C and use them together with 'play-sound' to play
any sound file IIUC).
- My module has been successfully tested on Android, and should also work
on Windows. 'play-sound' doesn't work at all on Android, and passing
sound data as a string isn't supported on Windows.
>> Assuming you mean the miniaudio library itself, it seems there is
>> an official "split" version of it which contains both
>> "miniaudio.c" and "miniaudio.h", where the actual implementation
>> lives inside "miniaudio.c".
> That makes sense to me -- it is common practice. How does the
> version you use differ from that?
The version I use (which is the "main" version) combines "miniaudio.c"
and "miniaudio.h" into a single file.
next prev parent reply other threads:[~2024-01-03 6:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-27 9:07 Vendoring code in a (Non?)GNU ELPA package Daniel Semyonov
2023-12-29 3:53 ` Richard Stallman
2023-12-29 4:14 ` No Wayman
2023-12-31 3:15 ` Richard Stallman
2024-01-01 3:37 ` Dmitry Gutov
2024-01-04 3:59 ` Richard Stallman
2024-01-01 12:07 ` Daniel Semyonov
2024-01-03 4:14 ` Richard Stallman
2024-01-03 6:20 ` Daniel Semyonov [this message]
2024-01-04 4:56 ` Stefan Kangas
2024-01-04 15:02 ` Daniel Semyonov
2024-01-05 20:10 ` Stefan Kangas
2024-01-06 10:52 ` Daniel Semyonov
2024-01-06 11:45 ` Stefan Kangas
2024-01-06 19:04 ` No Wayman
2024-01-08 3:46 ` Richard Stallman
2024-01-08 4:00 ` No Wayman
2024-01-10 12:07 ` Stefan Kangas
2024-01-06 4:35 ` Richard Stallman
2023-12-29 7:57 ` Daniel Semyonov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875y0bhrak.fsf@dsemy.com \
--to=daniel@dsemy.com \
--cc=emacs-devel@gnu.org \
--cc=iarchivedmywholelife@gmail.com \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).