23 Mar
2005
23 Mar
'05
7:40 p.m.
Hi,
If playing a sound file that has a different framerate from Jack, using
libsamplerate, should I :
- convert in real time, in the process callback ?
- convert the whole file into memory when loading it ?
Actually, I've already coded the second option, but just discovered the
jack_set_samplerate_callback() method, which seems to require the first
option... Is it important to support framerate changes while rolling ?
--
og
23 Mar
23 Mar
8:52 p.m.
New subject: [linux-audio-dev] Jack and sample rate conversion : realtime or not ?
Olivier Guilyardi <ml(a)xung.org> writes:
Hi,
If playing a sound file that has a different framerate from Jack, using
libsamplerate, should I :
- convert in real time, in the process callback ?
- convert the whole file into memory when loading it ?
Actually, I've already coded the second option, but just discovered the
jack_set_samplerate_callback() method, which seems to require the
first option... Is it important to support framerate changes while
rolling ?
No. That callback has never been implemented and may very likely be
removed from the interface.
--
joq
24 Mar
24 Mar
7:29 a.m.
New subject: [linux-audio-dev] Jack and sample rate conversion : realtime or not ?
Jack O'Quin wrote:
Olivier Guilyardi <ml(a)xung.org> writes:
Great :-)
Thanks
--
og
- convert in real time, in the process callback ?
- convert the whole file into memory when loading it ?
Actually, I've already coded the second option, but just discovered the
jack_set_samplerate_callback() method, which seems to require the
first option... Is it important to support framerate changes while
rolling ?
No. That callback has never been implemented and may very likely be
removed from the interface. 
4:45 a.m.
New subject: [linux-audio-dev] Jack and sample rate conversion : realtime or not ?
On Thu, Mar 24, 2005 at 12:40:23AM +0100, Olivier Guilyardi wrote:
Hi,
If playing a sound file that has a different framerate from Jack, using
libsamplerate, should I :
- convert in real time, in the process callback ?
- convert the whole file into memory when loading it ?
Hi,
my music player Aqualung (http://aqualung.sf.net) does the former,
however not in the JACK process callback (since it also supports ALSA
and OSS output) but in the disk thread which reads and decodes audio
files and resamples them (if necessary) in a buffer-by-buffer manner
via libsamplerate so it can be sent to the output thread.
If you're interested in the details, you may look at src/core.c in the
Aqualung codebase. Beware, though, that it's not particularly easily
readable by humans :)
Loading the whole file into memory sounds a bit pathologic IMHO (no
offense incl.)
Tom
7:28 a.m.
New subject: [linux-audio-dev] Jack and sample rate conversion : realtime or not ?
Hi Tom,
Tom Szilagyi wrote:
Thanks for pointing that third option :
- convert in the disk thread
- convert in
real time, in the process callback ?
- convert the whole file into memory when loading it ?
my music player Aqualung (http://aqualung.sf.net) does the former,
however not in the JACK process callback (since it also supports ALSA
and OSS output) but in the disk thread which reads and decodes audio
files and resamples them (if necessary) in a buffer-by-buffer manner
via libsamplerate so it can be sent to the output thread. If you're interested in the details, you may look
at src/core.c in the
Aqualung codebase. Beware, though, that it's not particularly easily
readable by humans :)
I'll try and check that out when I'm about to add support for streaming from
disk.
Loading the whole file into memory sounds a bit
pathologic IMHO (no
offense incl.)
I ain't that pathologic for a sequencer/drummachine as my application Jackbeat
(http://xung.org/jackbeat), where sound files are often small ones. But I want
to add configurable support for disk-streaming at some point in the future. For
now, loading the sample into memory is a simple and efficient method, which
AFAIK is pretty common in trackers, for example.
Additionally, because Jackbeat is supposed to support an unlimited number of
tracks, it may be required to stream many (16,32,64,..) sound files from disk in
parallel, which is not very smart either.
The main reason I was afraid of putting the sample rate conversion routines in
the realtime Jack thread is CPU load : the best quality libsamplerate converter
is pretty heavy. Imagine that with 32 tracks... Now, I could add an option like
"Which libsamplerate's converter do you want to use ?", so that people can
tweak
it according to their CPU power.
However, IMHO, converting when loading the sample has the advantage to allow
slow CPUs to use the best converter. Currently "loading" means allocating
memory, but that could also mean creating temporary files, and streaming from these.
Needs a bit more thinking though.
Thanks
--
og
6984
days inactive
6985
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Jack O'Quin -
Olivier Guilyardi -
Tom Szilagyi