eDrummer beta

Discuss anything new and newsworthy! See http://planet.linuxaudio.org and https://libreav.org/news for more Linux Audio News!

Announcements of proprietary software may fit better in the Marketplace.


Moderators: raboof, MattKingUSA, khz

j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: eDrummer beta

Post by j_e_f_f_g »

male wrote:Each processor instruction does not delay the audio
That's not a true statement, is not what i'm specifically talking about vis a vis double buffering, and actually doesn't speak to latency. It all depends upon whether there was room in the dma buffer for new audio data, but output of that data is postponed because earlier "pre-fetched" data is still being writtten to the dma buffer. Jack prefetches data in secondary (double) buffers. eDrummer doesn't.
you're not just a fool, you're a liar.
Do you always resort to ad hominems, or only whenever someone notes how you're incorrect.

The question again,: Are you actually suggesting that jack doesn't double buffer?

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

male
Established Member
Posts: 232
Joined: Tue May 22, 2012 5:45 pm

Re: eDrummer beta

Post by male »

j_e_f_f_g wrote:
male wrote:Each processor instruction does not delay the audio
That's not a true statement, is not what i'm specifically talking about vis a vis double buffering, and actually doesn't speak to latency. It all depends upon whether there was room in the dma buffer for new audio data, but output of that data is postponed because earlier "pre-fetched" data is still being writtten to the dma buffer. Jack prefetches data in secondary (double) buffers. eDrummer doesn't.
you're not just a fool, you're a liar.
Do you always resort to ad hominems, or only whenever someone notes how you're incorrect.

The question again,: Are you actually suggesting that jack doesn't double buffer?
What JACK are we even talking about? The only situation with JACK that meets any definition of buffering is the async mode, which is new in JACK2 and entirely optional.

In any case, you're merely attempting to change the subject. Your claims are and have always been about latency. Now you want to talk about async mode for some reason. Could it be because you simply can't admit that you are wrong?
Image
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: eDrummer beta

Post by j_e_f_f_g »

male wrote:The only situation with JACK that meets any definition of buffering is the async mode, which is new in JACK2 and entirely optional.
Is your answer to the question therefore "jack2 doesn't double buffer except in async mode, and jack1 doesn't all."?
Now you want to talk about async mode
You're arguing with your own strawman again. I haven't talked about it at all.
Could it be because you simply can't admit that you are wrong?
Non sequitor, for the reason given above.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

male
Established Member
Posts: 232
Joined: Tue May 22, 2012 5:45 pm

Re: eDrummer beta

Post by male »

j_e_f_f_g wrote:
male wrote:The only situation with JACK that meets any definition of buffering is the async mode, which is new in JACK2 and entirely optional.
Is your answer to the question therefore "jack2 doesn't double buffer except in async mode, and jack1 doesn't all."?
Now you want to talk about async mode
You're arguing with your own strawman again. I haven't talked about it at all.
Could it be because you simply can't admit that you are wrong?
Non sequitor, for the reason given above.
Jeff, I'm not going to answer your question the way you want it answered. The term 'double buffering' doesn't have any relevance to this conversation at all and you're only using it because either you don't know what you're talking about, or you're trying to be intentionally misleading and manipulative, or both.

You don't run this show. You go around making some pretty extraordinary claims and backing them up with nonsense instead of evidence. I'm here to call your BS.
Image
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: eDrummer beta

Post by j_e_f_f_g »

male wrote:I'm not going to answer your question the way you want it answered.
It's a simple question. Assuming you can answer it, try doing so in any way other than your usual desperate ad hominems.
The term 'double buffering' doesn't have any relevance to this conversation at all
Absolutely completely false. The discussion is about the latency associated with prefetching data in secondary buffers.

The rest of your post is your usual desperate ad hominems.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

male
Established Member
Posts: 232
Joined: Tue May 22, 2012 5:45 pm

Re: eDrummer beta

Post by male »

j_e_f_f_g wrote:
male wrote:I'm not going to answer your question the way you want it answered.
It's a simple question. Assuming you can answer it, try doing so in any way other than your usual desperate ad hominems.
The term 'double buffering' doesn't have any relevance to this conversation at all
Absolutely completely false. The discussion is about the latency associated with prefetching data in secondary buffers.

The rest of your post is your usual desperate ad hominems.
There is not a word of your post that isn't nonsense, Jeff. Now you how do you expect me to respond to your nonsense with a yes or no answer?

And now we're back to latency, are we? Why don't you concentrate on that then. You can claim there's latency associated with any imaginary structure you come up with and choose to call by whatever name. Secondary buffers or gremlins, I don't care. The point is simply that you can't prove it, because you're wrong. You're so wrong it's painful. Just do the measurements and see for yourself. It's OK, you can lie to us about the results--I expect no less from you, but at least you'll see it, and maybe that'll be enough to make you think twice the next time you're about to go spouting off about the way JACK works.
Image
dawhead
Established Member
Posts: 32
Joined: Fri Oct 09, 2009 2:50 pm
Has thanked: 2 times
Been thanked: 9 times

Re: eDrummer beta

Post by dawhead »

j_e_f_f_g wrote:. It all depends upon whether there was room in the dma buffer for new audio data, but output of that data is postponed because earlier "pre-fetched" data is still being writtten to the dma buffer. Jack prefetches data in secondary (double) buffers.
I don't like to use the term "liar" online. Even in my frequent political discussions.

I don't understand why you think you know more about how JACK works than the guy who wrote JACK in the first place (me). But whatever the reason, comments like the above are so close to being a lie that the term "liar" is almost warranted.
dawhead
Established Member
Posts: 32
Joined: Fri Oct 09, 2009 2:50 pm
Has thanked: 2 times
Been thanked: 9 times

Re: eDrummer beta

Post by dawhead »

For a brief interlude, I'm going to try to take your ignorance/confusion seriously.

Let us suppose that we got into the heart of eDrummer's audio I/O code. Rather than "copying data directly into the DMA buffer", as you (presumably correctly) note it already does, let us instead suppose that we modified that code. Let us suppose that the modifications involved 10,000 copy operations from one internal buffer to another before the final copy, that actually moves the data into the DMA buffer.

What is the result of this change? Does the latency of eDrummer change? No. The signal still makes it out to the hardware in time to meet the hardware deadlines, just as it did before. We did a bunch of pointless copies, it is true, but the timing from the perspective of the listener hasn't changed by 1 sample.

Does its CPU utilization change? Yes, by a very, very tiny amount.

So what it is that you're trying to say?
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: eDrummer beta

Post by j_e_f_f_g »

dawhead wrote:The signal still makes it out to the hardware in time to meet the hardware deadlines, just as it did before. We did a bunch of pointless copies, it is true, but the timing from the perspective of the listener hasn't changed by 1 sample.
Did you not read this entire thread and therefore note the whole purpose of edrummer and the latency tests of my beta tester? edrummer is a live performance soft synth specifically to trigger drum samples from midi pads. The listener is a drummer playing those pads. His perspective is that, when he strikes a pad, a drum sound is heard immediately. He tried several jack using apps such as hydrogen and linuxsampler and felt there was too much lag. He has a hardware setup he uses to measure latency. (See his link for info. Actually rather clever). The latency between input and output was too much for him. He tried edrummer and not only did "the timing from the perspective of the listener... change" -- he actually measured a significant drop in latency via his test setup. Right here is an actual test case that refutes your statement.

The reason why edrummer's latency is lower is because it doesn't prefetch data for the next dma cycle. It doesn't need to, because unlike the jack daemon, edrummer's next cycle of data is already in its process address space. edrummer does not predetermine what waveform data will be copied into the next cycle. Jack does so by prefetching client data in secondary buffers -- which may even be copied to further secondary buffers. Up until the very moment alsa signals edrummer to write the next cycle, any and all received (midi) input will determine what audio data gets written. Since jack has already prefetched the client;s data for the next cycle, the client can't get the new data out until the cycle after next. That represents a very real increase in latency that my tester both perceived and measured. And contrary to male's false implication, this has nothing to do with the -p setting. This latency is a factor of the amount of data jack prefetches in secondary client (ie, double) buffers.

Since male can't do anything useful beyond whining "you're wrong, loser", I directly put the question to you: Do you deny that jack prefetches (in a secondary -- not the dma -- buffer) the client's data for the next dma cycle?

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

luster
Established Member
Posts: 221
Joined: Mon Mar 05, 2012 10:03 pm

Re: eDrummer beta

Post by luster »

I think male does much bettah than:

[quote]... I directly put the question to you: Do you deny that jack prefetches (in a secondary -- not the drama -- buffer) the client's drama for the next drama cycle? [/drama]


Yeah

There, I said it

so, what of MOV AX,CX?
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: eDrummer beta

Post by j_e_f_f_g »

luster wrote:what of MOV AX,CX?
What in god's name are you going on about?? Did you lose a link to a MASM support forum? ::rolls eyes::

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

luster
Established Member
Posts: 221
Joined: Mon Mar 05, 2012 10:03 pm

Re: eDrummer beta

Post by luster »

j_e_f_f_g wrote:
luster wrote:what of MOV AX,CX?
What in god's name are you going on about?? Did you lose a link to a MASM support forum? ::rolls eyes::
I think your fundamental timing is a bit off.

And, yes, I did indeed [choose to] lose my link to MASM. But I prefer to think of it differentially.
falken
Established Member
Posts: 21
Joined: Mon Sep 02, 2013 1:28 am

Re: eDrummer beta

Post by falken »

@jeff: honestly, if jack internal "tick" of processing audio blocks is bound to "-p" (async adding exactly ONE more such buffer only??), then having 16 here, its 16/48000 for example, so 0.3ms; then if everything jackd needs to do against all connected clients fits in 0.3ms (not easy on each HW, ya), where is the problem? YES, its CPU bound a LOT, as demand on it goes higher with shorter buffer and more clients (with 64 samples its 64/48000, so 1.3ms, still very acceptable, until roundtrip latency together with HW devices is below say, 5ms - as you want "midi-in/audio-out", I dont know about input, how midi works here, but its even more trivial and much of latency can still depend more on HW driver? - probably usb-audio class midi?) - whats yours and your beta-tester CPU/MB in fact?? For me, it looks like you cant go down to such speed enough... Sure, that if you dont use jackd than you CAN achieve low latency with FAR slower CPU, no doubt - without the jackd flexibility though. (Even that I like AMD APU in my NB, I understand that desktop i7 can do LOT more here, particulary for CPU-bound DAW :-)

@all: be nice, fights arent usefull; win/mac is laughing :-)

Petr
dawhead
Established Member
Posts: 32
Joined: Fri Oct 09, 2009 2:50 pm
Has thanked: 2 times
Been thanked: 9 times

Re: eDrummer beta

Post by dawhead »

j_e_f_f_g wrote:[
Since male can't do anything useful beyond whining "you're wrong, loser", I directly put the question to you: Do you deny that jack prefetches (in a secondary -- not the dma -- buffer) the client's data for the next dma cycle?
it is clear that you like to play games with words and meanings, so i don't want to answer your question directly as worded. oh, all right then. yes, i deny it.

JACK is woken up by the audio interface hardware using the same mechanism that eDrummer uses (the ALSA one). the interface hardware does this because its buffer pointer has just passed a position where one period's worth of data/space is now available to user space for reading/writing. you can't change this (even if there are betters way to do this) because this is baked into ALSA's driver model.

lets make this concrete. if you configured the device to use 2 periods of 16 samples each, there is a h/w buffer of 32 samples. each time the h/w pointer passes the start/end or the midpoint of this buffer, it interrupts the CPU, then it gets back to processing the upcoming chunk of 16 samples. it is the responsibility of the CPU/system/kernel/application code to read/write the next 16 samples while the audio interface processes the other 16. ALSA provides you with no access to the 16 sample section of the buffer that the hardware is about to process, only to the other 16 that have just been written to/read from by the hardware.

So, you now have 16 samples worth of time to do whatever processing is necessary to get the other 16 samples set up in the DMA buffer. You can do this any way you want to, and take as much time as you want as long as you don't exceed the time represented by 16 samples. You can copy your data a gadzillion times before finally putting it in the DMA buffer, just as long as you get it there by the time the pointer hits the next period boundary. Nothing that you can do in your processing code will change the latency of the system - in 16 samples from the point of the interrupt, the h/w will start processing data that it assumes you put in the DMA buffer.

And JACK does exactly that. Yes, clients may write/read to/from all many of other buffers during the process callback cycle, but at the end of it, the data from all clients ends up back in the DMA buffer, just as it would if they were all native ALSA applications. The interrupt comes in, JACK wakes up, does a bit of housekeeping, the backend reads the incoming data from the DMA into buffers that clients can access, then wakes up all the clients who write into other buffers, then the backend writes data from those buffers back into the DMA buffer and JACK goes back to sleep.

No pre-fetching, no delay. Only "right now", just as with ALSA-native (or ASIO-native or CoreAudio-native or whatever-native) applications.

The term "double buffering" when used by people who understand audio device driver implementation and design describes precisely the scheme I've outlined above. To put it in more colloquial terms: the hardware divides the h/w ("DMA") buffer into two halves. It uses one half while the CPU gets to "use" the other. Every time it crosses the boundary between the two halves, it tells the CPU. The same design has historically been used in video interfaces too.

Now, there *are* things that one could ask for in an audio interface driver design that would change this mechanism a bit. In particular, you might want to be able to write/read closer to the h/w pointer than the smallest interrupt interval that the device will support (for example, many PCI interfaces won't go below 64 samples between interrupts, which thus defines a lower limit on the latency they can support with this kind of mechanism). If you knew where the h/w pointer was at any time, not just when the device sends an interrupt, you could figure out a way to do this.

And indeed ... you could decouple the wakeup from the h/w for example, by using a DLL and very accurate system clock. CoreAudio on OS X does this, allowing different apps to use the same hardware but be woken at different intervals, thus allowing them to have different latencies even though they all share a single hardware setup. The DLL allows you to predict/guess/know where the h/w pointer is at any point in time with great accuracy, and so rather than wait for the hardware itself to tell you "time to read/write more data", you can just wake up at various intervals and "know" exactly how much data/space there is available to read/write. Of course, CoreAudio isn't super-confident of the accuracy of its DLL and so they add a "safety buffer" - basically they waffle a bit on where the DLL predicts the h/w pointer is to ensure that if the DLL isn't completely accurate, underruns/overruns won't happen. Typically safety buffer sizes are 8 samples - the size is determined by the device driver. This design means that you can safely write pretty much anywhere in the h/w ("DMA") buffer because you know very accurately where the h/w pointer is. If the DLL and the hardware are solid enough, you could even write into the DMA buffer just 1 sample ahead of the h/w pointer, generating just 1 sample's worth of output latency. Unfortunately, this is a theoretical possibility only for consumer level cards, because of the lower limit on the PCI burst transfer size - you need to cook up at least 64 bytes of data to do the DMA transfer.

But ... ALSA doesn't offer such a mechanism. It doesn't have a DLL to predict the h/w pointer position - ALSA is entirely dependent on the interrupts to know that. Moreover, there is hardware where any attempt to access the part of the DMA buffer actively in use by the h/w will fail. And worse, there are still audio interfaces floating around out there where is no DMA buffer at all - the device driver has to actively move data to and from the card via IO ports, and there is no DMA access for either the kernel or user space. ALSA hides this from in its API - you don't actually have any idea whether the "DMA" buffer that you get access to from user space is actually memory associated with DMA or just another internal buffer in ALSA that it will eventually need to read/write to the device via some other mechanism. Thankfully, such audio interfaces are now rare, but even in the early 2000's the fact that an audio interface could be a DMA bus master was a big deal.

In summary, the only way you get to read/write data from/to an audio interface is when the kernel tells you it is time to do so. The kernel has its own mechanism for this, and with ALSA on Linux, that mechanism is based on interrupts from the device. When an interrrupt comes in, and your application is woken up to do I/O, you can only read/write the next period's worth of data if you want to read/write it directly from/into the DMA buffer. As long as you get that done before the next period elapses, everything is good - no data is lost, no clicks are heard. But this (1 period) is the lower limit for latency on an ALSA-driven system, and JACK and its clients match this limit just like any native ALSA app would (admittedly with a bit more CPU overhead) - they read/write the relevant data within the next period, and the data they generate is in the DMA buffer at the end of it, ready for use by the hardware.

(note: the above discussion does not relate to JACK2's "async" mode, which as has been noted is optional and not available in JACK1)
Pablo
Established Member
Posts: 1274
Joined: Thu Apr 17, 2008 9:57 pm
Been thanked: 3 times

Re: eDrummer beta

Post by Pablo »

Hats off to you, Paul! Thanks for the light. Now, I hope you make up with each other! :D
Post Reply