eDrummer beta

[j_e_f_f_g]

I just spoke to Paul Davis on IRC, the original author of JACK.
He says that your explanation is factually wrong, misleading and fundamentally incorrect in every way.

In what specific ways? If "every way" surely your "savior", from that guy who tirelessly talks about what's in the code, can rattle off a very long list? The actual source tells the story. (Although here I'm talking about jack2 since male referred to -p. I don't think davis is behind jack2, and there are some differences with jack1).

My impression of the jack author is that he vastly oversells the capabilities/performance of his software. He's a lot salesman, which is fine. He promotes his software. You just have to be aware when he says something like "this software adds no latency", his mindset is to instinctively couch it in the most favorable, generous light. For example, he means "this software adds no latency beyond any other software that routes audio between processes, and double/triple buffers, and uses sockets to communicate, etc -- ie, any framework that adds a lot of overhead". Which is pretty much true. But what about software that doesn't do that? Well, he didn't say anything about that. And most likely that's the end of useful discussion.

I strongly recommend audio devs take a serious study of the alsa and jack codebases. There's lots of undocumented stuff in there, and probably for good reason. for example, you may be amazed/appalled at the endrun around the alsa userspace lib jack2 does. Want to know what? Read those sources!

[male]

JACK running at -p 16

Um no, you are confused by the numbers. That doesn't represent the buffer latency of the jack app. That's simply the value jack passes to ALSA's snd_pcm_hw_params_set_rate_near(), to set the soundcard's dma buffer size. See line 437 of the jack source code file linux/alsa/alsa_driver.c, and trace it back. (BTW snd_pcm_hw_params_set_rate_near may or may not give you the requested value. See my comments earlier in this thread where I talk to my beta tester about his latency tests to make sure it was all done correctly).

You're talking nonsense.

That would be one thing if, like edrummer, a jack app was signaled directly by alsa, and wrote its (linear integer) output directly to the soundcard dma buffer. But it doesn't! The jack app instead waits on a jack socket (see the jacklib source code for the jack_activate function). Alsa signals the jack daemon who starts writing to those sockets, giving each app its own secondary float software buffer to fill. jack gets those buffers, and perhaps passes some of them on to other clients. jack then mixes these float buffers to the linear int format requiired by the soundcard, doing any sample rate conversion (see JackLibSampleRateResampler.cpp) and bit resolution conversion (see memops.c) needed. During all this time at 16 frames dma, I can guarantee that dma buffer has been filled numerous times. It's not like audio stops. where does jack get the audio data? jack allocates its own secondary "mix buffer" (a ring buffer much larger than the dma buffer) into which client data is mixed. (See the AudioBufferMixdown function in JackAudioPort.cpp and trace forward). And jack keeps this larger ring buffer constantly prefilled with mixed client data to feed the card. It is this buffer that represents app latency. This is the one that needs to be 200 frames where edrummer needs only 16 on the same system. And that's because I don't do double (triple when you count app buffers) buffering, socket reads/writes, and process switching to get things done.

'a buffer' is not the same thing as 'buffering'. As even you seem to understand at least a little with your talk of integer<->float conversion, the purpose of these structures is to transform the sample data, not to delay it in any way (which most certainly doesn't do). You appear to have deep and fundamental misunderstandings about how digital audio works period. No, Jeff, sound doesn't stop. I suppose your eDrummer is really an analog circuit now too, in addition to having magic, time dilation powers.

Why don't you stop spouting lies and nonense and actually measure your device? If you had any sense you'd find the results shockingly enlightening.

[male]

one quick example for this latency confusion of yours is patchfield.
https://github.com/google/patchfield

it runs a patch graph in a way similar to jack, but for android.

Patchfield incurs no latency on top of the systemic latency of the Android audio stack; the audio processing callbacks of all active modules are invoked in one buffer queue callback of OpenSL ES.

ignoring the oddities with android and audio with java, JACK works essentially the same way.
we have a single ALSA application running that allows external clients.
all the processing is still done during 1 ALSA audio callback.

jack2 has 2 operation modes though - sync and async.
the async mode really adds 1 cycle of latency but clients processing is multi-threaded; the sync mode has no extra latency at all but clients processing is single-threaded.

Correct, except that --sync mode in JACK2 does not disable the multi-threaded processing of JACK clients. All it disables the new 'async' feature of JACK2 where the output of the previous period is written to the sound card while the current period is being executed.

But yeah, on Linux, the JACK server *is* an ALSA client. It's just one that happens to use (allow) a bunch of other processes (JACK clients) to do the actual DSP.

[j_e_f_f_g]

the purpose of these structures is to transform the sample data.

Totally incorrect. The mix buffer is float data too. The memcpy() of the first client's buffer to the mixbuffer, followed by summing in of others, should have clued you into its purpose. Data conversion doesn't happen until data is pulled out of the ring buffer and transfered to the soundcard dma buffer. That doesn't happen until alsa_driver_write() in linux/alsa/alsa_driver.c. (Specifically line 57's call to WriteOutput, which ultimately calls the jack function that converts float to the soundcard format, with rate/bit conversion if needed. An example of such a conversion function is sample_move_dither_rect_d16_sSs in common/memops.c). And this doesn't happen until after the ring buffer is pre-filled with a mix (sum) of client buffers in common/JackPort.cpp MixBuffers(). It's effectively a latency buffer since client data is pre-queued for output via this mechanism. Read the #%@ source.

"a buffer is not the same thing as buffering"? I think I read that once in a fortune cookie on the Dr. Phil Show set. Sounds about right.

[j_e_f_f_g]

all the processing is still done during 1 ALSA audio callback

Of course. But via the use of double-buffering, i.e. queued data. And that represents latency from "right now". After all, new data can't skip ahead of data that is queued.

[dawhead]

all the processing is still done during 1 ALSA audio callback

Of course. But via the use of double-buffering, i.e. queued data. And that represents latency from "right now". After all, new data can't skip ahead of data that is queued.

you're the guy who claimed to follow the code to find out that the number given via the -p flag ends up being used in a call to set the sample rate in ALSA. you did this aggressively to claim that another developer with years of experience "doesn't understand JACK".

why the hell are you still talking about this?

[raboof]

http://home.roadrunner.com/~jgglatt/edrummer.zip

This URL 404's for me, has it moved?

I don't see it on http://home.roadrunner.com/~jgglatt/progs/linux.htm yet either, but perhaps you're in the progress of moving it?

[j_e_f_f_g]

you... claim... the number given via the -p flag ends up being used in a call to set the sample rate in ALSA.

Absolutely untrue. I never made any such claim. I corrrectly stated that it sets the soundcard dma buffer size.

I then went on to explain specifically why this setting, unlike with edrummer, does not determine a jack app's latency, contrary to male's misleading implication.

you did this aggressively to claim that another developer with years of experience "doesn't understand JACK".

Reading minds to ascertain motives, are we Miss Cleo? Wrong again. I posted to correct male's misleading implication. Which I did.

why the hell are you still talking about this?

Because there have been further misleading and/or factually incorrect repliies posted, such as yours to which I'm replying now.

[j_e_f_f_g]

you're in the progress of moving it?

Well right now I'm updating it with new features that were postponed while I was working out some low level details with my tester. Plus I need to write suittable docs for it.

Only some of the software has made it to my new page at this time. I'll be announcing updates as they happen.

[dawhead]

you... claim... the number given via the -p flag ends up being used in a call to set the sample rate in ALSA.

Absolutely untrue. I never made any such claim. I corrrectly stated that it sets the soundcard dma buffer size.

hmm, lets see:

Um no, you are confused by the numbers. That doesn't represent the buffer latency of the jack app. That's simply the value jack passes to ALSA's snd_pcm_hw_params_set_rate_near(), to set the soundcard's dma buffer size.

So lets take a look just to humor you:

Code: Select all

	
frame_rate = driver->frame_rate ;
err = snd_pcm_hw_params_set_rate_near (handle, hw_params,
					       &frame_rate, NULL) ;
driver->frame_rate = frame_rate ;

this doesn't use the value given for the -p argument, it uses the value given for the -r argument. given that both keys are on the home row, we could perhaps believe you made a typo, but looking back at the context that seems unlikely. moreover, lets take a look at the docs on [tt]snd_pcm_hw_params_set_rate_near()[/tt] .. "Restrict a configuration space to have rate nearest to a target. " i.e it has absolutely nothing to do with buffer size at all.

I then went on to explain specifically why this setting, unlike with edrummer, does not determine a jack app's latency, contrary to male's misleading implication.

and your explanation was completely and utterly wrong. in almost every possible way, from cited code, to relevant parameters, to details of how modern and not-so-modern audio hardware works, to ALSA functionality, to JACK design ... just wrong, wrong, wrong.

you did this aggressively to claim that another developer with years of experience "doesn't understand JACK".

Reading minds to ascertain motives, are we Miss Cleo? Wrong again. I posted to correct male's misleading implication. Which I did.

I'm not reading minds. I'm reading this:

Um no, you are confused by the numbers.

and this

I've explained this to you before and you continue with your... well "lies and misinformation" about jack and alsa. It's obvious to me that you haven't studied the alsa and jack codebases, you therefore don't have the tech knowledge to comment on this topic, and by talking about the -p setting, you have no idea how latency manifests in jack, much less alsa.

That's aggressive, whether you intended itor not. And yes, for the benefit of others reading this, I do intend to be aggressive myself, because your posts here are full of crap.

why the hell are you still talking about this?

Because there have been further misleading and/or factually incorrect repliies posted, such as yours to which I'm replying now.

Dude, I designed and wrote JACK. I played a significant role in the design of the ALSA APIs that JACK and eDrummer are using. I'm telling you that the things you are posting here are wrong. I'm asking you STFU because you're creating another breadcrumb trail of incorrect assertions about audio I/O on linux, computers in general, with JACK, with ALSA and a bunch of other stuff. Please just shut up and go back to writing code. If you don't want to use JACK, that's fine. But please stop spouting off about stuff that you've failed to understand (or at least, failed to demonstrate understanding in what you post here).

[j_e_f_f_g]

Indeed, I cited the wrong alsa call. It's snd_pcm_hw_params_set_period_size() to set the dma buffer window. And I stand by my assessment that doesn't determine a jack app's latency, because of jack's use of additional (double) buffering. A jack app writes to a secondary buffer, not the mmap'ed buffer.

Is that all you got -- snd_pcm_hw_params_set_period_size?

[male]

Indeed, I cited the wrong alsa call. It's snd_pcm_hw_params_set_period_size() to set the dma buffer window. And I stand by my assessment that doesn't determine a jack app's latency, because of jack's use of additional (double) buffering. A jack app writes to a secondary buffer, not the mmap'ed buffer.

Is that all you got -- snd_pcm_hw_params_set_period_size?

Are you really that dense, Jeff? Just because a program writes to and reads from some memory locations, does not mean it is 'buffering', 'queuing' or in any other way delaying the data. This is programming 101 shit here, Jeff. I suppose you think that applying gain to a sample adds 1 sample of latency? That's the logic you're using and it is as wrong as anything can possibly be.

[j_e_f_f_g]

Just because a program writes to and reads from some memory locations, does not mean it is 'buffering', 'queuing' or in any other way delaying the data.

It does if the data has to be copied out of a secondary buffer into a destination buffer (here the dma buffer), versus just writing directly to the destination. In programming 101, you'll learn the former is callled "double buffering", and incurrs extra processing time. Jack apps do that. eDrummer doesn't.

Are you actually suggesting that jack doesn't double buffer??

you think that applying gain to a sample adds 1 sample of latency

I never made such a statement. You're arguing with your own strawman again.

That's the logic you're using

Non sequitor, for the reason given above.

[male]

Just because a program writes to and reads from some memory locations, does not mean it is 'buffering', 'queuing' or in any other way delaying the data.

It does if the data has to be copied out of a secondary buffer into a destination buffer (here the dma buffer), versus just writing directly to the destination. In programming 101, you'll learn the former is callled "double buffering", and incurrs extra processing time. Jack apps do that. eDrummer doesn't.

Are you actually suggesting that jack doesn't double buffer??

Jeff, do you understand that each processor instruction does not delay the audio? We're talking about audio samples that are processed in blocks. You can run as many operations against each sample as you want, you can copy them around between a million buffers and still not delay the signal by a single sample. If you understood anything about digital audio, you'd know this.

And if you do know it, but are pretending not to, you're not just a fool, you're a liar.

[luster]

CPU instruction [MOV AX,CS for instance] requirements are on a different time-scale than audio sample rate.