18 Jan
2018
18 Jan
'18
12:58 a.m.
I'm getting a little confused when comparing our (Jack) buffer sizes with those
discussed on Windows, Mac and general music groups.
These latter never mention periods at all, and it's always frames per buffer,
so when trying to make comparisons should I take buffers as 1:1 or should I be
comparing their buffers to our periods?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
18 Jan
18 Jan
1:05 a.m.
a JACK or ALSA "period" is what almost everything on windows and MacOS
calls a "buffer".
they do not have a term for what ALSA calls "a buffer" (the entire memory
space available for audio i/o, typically mmapped into the using process'
address space)
just about all modern audio interfaces use a double-buffer design. while
the application writes/reads to one buffer, the hardware reads/writes from
the other.
On Wed, Jan 17, 2018 at 6:58 PM, Will Godfrey <willgodfrey(a)musically.me.uk>
wrote:
I'm getting a little confused when comparing our
(Jack) buffer sizes with
those
discussed on Windows, Mac and general music groups.
These latter never mention periods at all, and it's always frames per
buffer,
so when trying to make comparisons should I take buffers as 1:1 or should
I be
comparing their buffers to our periods?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
11:44 p.m.
Thanks Paul. That's something like what I was hoping was the case.
I can now continue to quietly feel a little smug when the 'others' are
enthusing about being able to work *even* with a buffer size of 64, while I've
been using a period size of 32 for most stuff :)
On Wed, 17 Jan 2018 19:05:40 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
a JACK or ALSA "period" is what almost
everything on windows and MacOS
calls a "buffer".
they do not have a term for what ALSA calls "a buffer" (the entire memory
space available for audio i/o, typically mmapped into the using process'
address space)
just about all modern audio interfaces use a double-buffer design. while
the application writes/reads to one buffer, the hardware reads/writes from
the other.
On Wed, Jan 17, 2018 at 6:58 PM, Will Godfrey <willgodfrey(a)musically.me.uk>
wrote:
> I'm getting a little confused when comparing our (Jack) buffer sizes with
> those
> discussed on Windows, Mac and general music groups.
>
> These latter never mention periods at all, and it's always frames per
> buffer,
> so when trying to make comparisons should I take buffers as 1:1 or should
> I be
> comparing their buffers to our periods?
>
> --
> Will J Godfrey
> http://www.musically.me.uk
> Say you have a poem and I have a tune.
> Exchange them and we can both have a poem, a tune, and a song.
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
>
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
1:37 a.m.
On 01/17/2018 06:58 PM, Will Godfrey wrote:
I'm getting a little confused when comparing our
(Jack) buffer sizes with those
discussed on Windows, Mac and general music groups.
These latter never mention periods at all, and it's always frames per buffer,
so when trying to make comparisons should I take buffers as 1:1 or should I be
comparing their buffers to our periods?
Hi Will.
From memory on Windows years ago, and if I understand Jack correctly,
Jack, or more specifically ALSA (in this case let's say using the
ALSA driver), puts you much lower-level towards the sound hardware.
You get to specify the period size and the number of periods.
This usually means that you are specifying the size of a hardware
Direct Memory Access (DMA) buffer and the number of such buffers
to use. More importantly, that buffer size and the sample rate
determine the hardware interrupt rate.
If I may make a comparison: Think video games. To avoid 'tearing'
(motion artifacts) on the screen, we draw graphics on an
off-screen buffer while another buffer is actually being displayed.
The system continuously about 60 times a second or more 'flips' which
of these buffers are displayed so now the buffer you just wrote is
being displayed while the one that was displayed can be safely
written to without causing tearing. But you must be quick and write
your inactive buffer before it 'flips' again. More than TWO buffers
may be used so that several off-screen buffers can be 'queued up'
for display.
So... The same idea with low(ish)-level RT audio. Jack, ALSA etc.
It will 'flip' among the number of buffers you specify.
List, please correct me if I am wrong here, it has been a while (~2005):
I recall testing Windows, even DirectX (DirectSound), and no
matter what I did I could /not/ get that hardware interrupt
rate to change. I tried exclusive mode etc etc.
I seemed that Windows was just providing me with yet another layer.
Hence if I recall, there is only *one* buffer to specify, and
Windows does the rest. (Regular Multi-Media audio is different.)
Darn, can't remember my DirectX too well, I was heavily into it...
Have things changed? Or have I messed that up that explanation?
Tim.
2:04 a.m.
On Wed, Jan 17, 2018 at 7:37 PM, Tim <termtech(a)rogers.com> wrote:
On 01/17/2018 06:58 PM, Will Godfrey wrote:
while true, this is not necessarily a benefit.
the better design here is to completely decouple everything as much as
possible from device interruptsm and use DLL's to provide sub-sample
accurate "prediction" of where an application can read and write at any
time.
this allows you to have multiple applications using different buffer sizes
(different latency), and to get better latency than the device's inherent
interrupt intervals would allow.
it's what coreaudio does, and ALSA should do it too. i doubt if it ever
will. pulse sort of does this, but all in user space.
I'm getting a little confused when comparing
our (Jack) buffer sizes with
those
discussed on Windows, Mac and general music groups.
These latter never mention periods at all, and it's always frames per
buffer,
so when trying to make comparisons should I take buffers as 1:1 or should
I be
comparing their buffers to our periods?
Hi Will.
From memory on Windows years ago, and if I understand Jack correctly,
Jack, or more specifically ALSA (in this case let's say using the
ALSA driver), puts you much lower-level towards the sound hardware.
2:22 a.m.
On 01/17/2018 08:04 PM, Paul Davis wrote:
On Wed, Jan 17, 2018 at 7:37 PM, Tim <termtech(a)rogers.com
<mailto:termtech@rogers.com>> wrote:
On 01/17/2018 06:58 PM, Will Godfrey wrote:
I'm getting a little confused when comparing our (Jack) buffer
sizes with those
discussed on Windows, Mac and general music groups.
These latter never mention periods at all, and it's always
frames per buffer,
so when trying to make comparisons should I take buffers as 1:1
or should I be
comparing their buffers to our periods?
Hi Will.
From memory on Windows years ago, and if I understand Jack correctly,
Jack, or more specifically ALSA (in this case let's say using the
ALSA driver), puts you much lower-level towards the sound hardware.
while true, this is not necessarily a benefit.
the better design here is to completely decouple everything as much as
possible from device interruptsm and use DLL's to provide sub-sample
accurate "prediction" of where an application can read and write at any
time.
Ha! Yeah I remember experimenting with that sort of thing.
Like you're in a race with the DMA pointers. Nice we could read them.
this allows you to have multiple applications using
different buffer
sizes (different latency), and to get better latency than the device's
inherent interrupt intervals would allow.
I've mused a few times about whether it would be possible to do
this with Jack midi when using large Jack buffer sizes ;-)
It's ironic because MusE supports both Jack midi (at say 2048 buffer)
and ALSA midi (with say 1024 Hz timer) at the same time.
it's what coreaudio does, and ALSA should do it
too. i doubt if it ever
will. pulse sort of does this, but all in user space.
How might sample rate conversion fit into this? Does it make it easier?
Or no difference, they might slap it on ahead of or after this layer?
So that say, we might not need the ALSA mixing layer (I forget what
it's called, dmix?).
T.
11:46 p.m.
On Wed, 17 Jan 2018 20:21:55 -0500
Tim <termtech(a)rogers.com> wrote:
On 01/17/2018 08:04 PM, Paul Davis wrote:
Very interesting info here, but I'm trying to understand a scenario where you'd
want different latencies within a single environment.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On Wed, Jan 17, 2018 at 7:37 PM, Tim <termtech(a)rogers.com
<mailto:termtech@rogers.com>> wrote:
On 01/17/2018 06:58 PM, Will Godfrey wrote:
I'm getting a little confused when comparing our (Jack) buffer
sizes with those
discussed on Windows, Mac and general music groups.
These latter never mention periods at all, and it's always
frames per buffer,
so when trying to make comparisons should I take buffers as 1:1
or should I be
comparing their buffers to our periods?
Hi Will.
From memory on Windows years ago, and if I understand Jack correctly,
Jack, or more specifically ALSA (in this case let's say using the
ALSA driver), puts you much lower-level towards the sound hardware.
while true, this is not necessarily a benefit.
the better design here is to completely decouple everything as much as
possible from device interruptsm and use DLL's to provide sub-sample
accurate "prediction" of where an application can read and write at any
time.
Ha! Yeah I remember experimenting with that sort of thing.
Like you're in a race with the DMA pointers. Nice we could read them.
this allows you to have multiple applications
using different buffer
sizes (different latency), and to get better latency than the device's
inherent interrupt intervals would allow.
I've mused a few times about whether it would be possible to do
this with Jack midi when using large Jack buffer sizes ;-)
It's ironic because MusE supports both Jack midi (at say 2048 buffer)
and ALSA midi (with say 1024 Hz timer) at the same time.
it's what coreaudio does, and ALSA should do
it too. i doubt if it ever
will. pulse sort of does this, but all in user space.
How might sample rate conversion fit into this? Does it make it easier?
Or no difference, they might slap it on ahead of or after this layer?
So that say, we might not need the ALSA mixing layer (I forget what
it's called, dmix?).
T.
19 Jan
19 Jan
12:07 a.m.
On Thu, Jan 18, 2018 at 5:46 PM, Will Godfrey <willgodfrey(a)musically.me.uk>
wrote:
Very interesting info here, but I'm trying to understand a scenario where
you'd
want different latencies within a single environment.
running low latency music creation or pro-audio software at the same time
as using a web-browser or skype or something else that has no need or
desire to be real-time safe.
1:10 a.m.
Am Donnerstag, den 18.01.2018, 18:07 -0500 schrieb Paul Davis:
On Thu, Jan 18, 2018 at 5:46 PM, Will Godfrey <willgodfrey@musically.
me.uk> wrote:
Then: What's missing to make pulseaudio being able to handle pro-audio
(and resolves us from the sound-server-mess :) )?
Greets!
Mitsch
Very interesting info here, but I'm trying to understand a scenario
where you'd
want different latencies within a single environment.
running low latency music creation or pro-audio software at the same
time as using a web-browser or skype or something else that has no
need or desire to be real-time safe. 
3:06 a.m.
On Thu, January 18, 2018 6:10 pm, Michael Jarosch wrote:
Then: What's missing to make pulseaudio being able
to handle pro-audio
(and resolves us from the sound-server-mess :) )?
Red Hat is working on something along those lines, but they decided to
also make the server support video, so that it is a full multi-media
server, not just audio. I think (my opinion only) that will make the task
so much more complicated that it will be years before there is a working
version that serves the use of PulseAudio and jack in a single server, if
they ever finish. Maybe I am too pessimistic, hopefully they will have a
proof of concept sometime this year.
https://pipewire.org/
--
Chris Caudle
4:25 p.m.
On Thu, 18 Jan 2018, Chris Caudle wrote:
On Thu, January 18, 2018 6:10 pm, Michael Jarosch
wrote:
Video too? Yikes! My first thought is that would make things easier.
Lowest latency would be one video frame... 30-ish ms, useless for live
audio effects/synth of course.
--
Len Ovens
www.ovenwerks.net
Then: What's missing to make pulseaudio being
able to handle pro-audio
(and resolves us from the sound-server-mess :) )?
Red Hat is working on something along those lines, but they decided to
also make the server support video, so that it is a full multi-media
server, not just audio. I think (my opinion only) that will make the task
so much more complicated that it will be years before there is a working
version that serves the use of PulseAudio and jack in a single server, if
they ever finish. Maybe I am too pessimistic, hopefully they will have a
proof of concept sometime this year.
3:33 a.m.
pulseaudio doesn't support the pull model audio API, and partially as a
result, can't get down to the kinds of latencies that JACK can.
On Thu, Jan 18, 2018 at 7:10 PM, Michael Jarosch <riotsound(a)riotmusic.de>
wrote:
Am Donnerstag, den 18.01.2018, 18:07 -0500 schrieb
Paul Davis:
On Thu, Jan 18, 2018 at 5:46 PM, Will Godfrey <willgodfrey@musically.
me.uk> wrote:
Then: What's missing to make pulseaudio being able to handle pro-audio
(and resolves us from the sound-server-mess :) )?
Greets!
Mitsch
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
Very interesting info here, but I'm trying to understand a scenario
where you'd
want different latencies within a single environment.
running low latency music creation or pro-audio software at the same
time as using a web-browser or skype or something else that has no
need or desire to be real-time safe.
3:36 a.m.
just to expand on that a bit. you can build a push model API on top of a
pull model API fairly easily; the other way around is hard.
all the pro-audio APIs that have ever existed use pull model, because it
implicitly respects and models the hardware's realtime constraints.
encouraging (forcing) applications to use this model is an important part
of why pull model APIs work.
On Thu, Jan 18, 2018 at 9:33 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
pulseaudio doesn't support the pull model audio
API, and partially as a
result, can't get down to the kinds of latencies that JACK can.
On Thu, Jan 18, 2018 at 7:10 PM, Michael Jarosch <riotsound(a)riotmusic.de>
wrote:
Am Donnerstag, den 18.01.2018, 18:07 -0500
schrieb Paul Davis:
On Thu, Jan 18, 2018 at 5:46 PM, Will Godfrey <willgodfrey@musically.
me.uk> wrote:
Then: What's missing to make pulseaudio being able to handle pro-audio
(and resolves us from the sound-server-mess :) )?
Greets!
Mitsch
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
Very interesting info here, but I'm trying to understand a scenario
where you'd
want different latencies within a single environment.
running low latency music creation or pro-audio software at the same
time as using a web-browser or skype or something else that has no
need or desire to be real-time safe. 
5:06 p.m.
just to expand on that a bit. you can build a push model API on top of a
pull model API fairly easily; the other way around is hard.
On a push model on top of pull, pull will overwrite if push is slow, how to
determine how much buffering is required. Any guideline.
-ben
-----
-ben
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-user-f5.html
5:15 p.m.
>just to expand on that a bit. you can build a push
model API on top of a
>pull model API fairly easily; the other way around is hard.
On a push model on top of pull, pull will overwrite if push is slow, how to
determine how much buffering is required. Any guideline.
-----
-ben
--
Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-user-f5.html
5:51 p.m.
On Fri, Jan 19, 2018 at 11:06 AM, benravin <ben.alex(a)outlook.com> wrote:
just to expand on that a bit. you can build a push model API on top of a
pull model API fairly easily; the other way around is hard.
On a push model on top of pull, pull will overwrite if push is slow, how
to
determine how much buffering is required. Any guideline.
You can't know ahead of time. You need to know the behaviour of your
non-realtime-safe data sources (e.g. disks).
For reference, in the case of Ardour, we buffer 5 seconds of audio per
track by default. This is enough in most cases, but not all; in some cases,
it is way more than necessary.
4:15 p.m.
On Fri, 19 Jan 2018, Michael Jarosch wrote:
Then: What's missing to make pulseaudio being able
to handle pro-audio
(and resolves us from the sound-server-mess :) )?
Pulse looses samples (I don't think it can even make sure left and right
channels have the same number of samples). It is ok for desktop things,
but I think it would need to be redone in everything that matters to be
"pro" usable. Pulse works well as an audio front end to jack if desktop
audio listening while needing sample perfect audio is required.
The PA-jack bridge could really use some love. It needs buffering of some
sort so that jack can run at a lower latency than pulse does. In short,
the pa-jack bridge needs to be redone to look like a device rather than a
bridge.
Still, I have found the PA frontend, jack backend to work very well so
long as pulse can see no real devices (remove the udev module and any alsa
modules from pulse). It will even handle jack gong into freewheel in this
case.
--
Len Ovens
www.ovenwerks.net
10 p.m.
On Thu, 18 Jan 2018 18:07:05 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Thu, Jan 18, 2018 at 5:46 PM, Will Godfrey
<willgodfrey(a)musically.me.uk>
wrote:
Well Ok, but personally I can't think of a circumstance where I would ever want
to do that. Indeed my DAW has no network connection at all unless I want to
update something.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Very interesting info here, but I'm trying to understand a scenario where
you'd
want different latencies within a single environment.
running low latency music creation or pro-audio software at the same time
as using a web-browser or skype or something else that has no need or
desire to be real-time safe. 
10:55 p.m.
On January 19, 2018 11:00:29 AM HST, Will Godfrey <willgodfrey(a)musically.me.uk>
wrote:
On Thu, 18 Jan 2018 18:07:05 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
time
Skype when collaborating with someone remotely. Or web browser when following
someone's "how to" video on YouTube.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
Sent from my Android device with K-9 Mail.
On Thu, Jan 18, 2018 at 5:46 PM, Will Godfrey
<willgodfrey(a)musically.me.uk>
wrote:
>
> Very interesting info here, but I'm trying to understand a scenario
where
you'd
want different latencies within a single environment.
running low latency music creation or pro-audio software at the same as using a web-browser or skype or something else
that has no need or
desire to be real-time safe.
Well Ok, but personally I can't think of a circumstance where I would
ever want
to do that.
2445
days inactive
2447
days old
linux-audio-user@lists.linuxaudio.org
18 comments
8 participants
participants (8)
-
benravin -
Chris Caudle -
David W. Jones -
Len Ovens -
Michael Jarosch -
Paul Davis -
Tim -
Will Godfrey