>>>>>>>>>>> <SNIP> >>>>>>> Where the rt-kernel helps is that when the sound card asks for data >>>>>>> there should be a much lower 'latency' from the sound card raising a >>>>>>> hardware flag to the ALSA driver requesting data to the kernel >>>>>>> supplying this data to the ALSA driver sending it out to the card. >>>>>>> Lower latency in the rt-kernel helps the buffer not run dry, but the >>>>>>> truth is that the audio is identical and all that matters is that the >>>>>>> buffer not run dry. >>>>>> >>>>>> Excellent description, thank you. So the question becomes, does the >>>>>> card's buffer ever run dry? Is there a way to find out? >>>>> >>>>> Using JAck - yes. It's called an xrun and Jack reports them clearly. >>>>> To the best of my knowledge when not using Jack the answer is no. >>>> >>>> I thought jack set up a buffer of its own. Does jack report on the >>>> sound card's buffer? >>>> >>> <SNIP> >>> >>> Correct - Jack reports it's own buffer - not the sound card's. The >>> filling of the sound card's buffer is managed by the card talking to >>> the Alsa driver. >>> >>> The one place where the card is in control is the *frequency* this all >>> occurs at. The card's internal crystal is used as the overall >>> controlling clock for Jack and is delivered through the Alsa driver. >>> This way Jack keeps the audio data flowing at the rate the sound card >>> requires. All of the audio apps then respond to Jack with the correct >>> number of samples per second. >> >> Do the sound card's buffer and jack's buffer mirror each other then? >> If not, I'm not sure monitoring jack's buffer will be helpful since it >> sounds like it's the status of the card's buffer that determines >> whether playback is perfect or not. >> >> - Grant >> > > To some extent yes - the data is the same and in the same order - > although the depth of the two buffers doesn't have to be the same. The > sound card might be 600 bytes deep (purposely chosen as a weird size > only to make the point) and your Jack buffer might be 256 bytes deep > because you want certain latencies. Jack accepts data in 256 byte > chunks from the Jack enabled audio app (your CD player or Ardour in my > case) and then holds it for delivery to the sound card as soon as the > card can accept 256 bytes. Again, as long as the card doesn't run > empty sound is perfect. As long as Jack & Alsa delivers 256 bytes > faster then the card uses 256 bytes the buffer doesn't run empty, but > the actual sizes of the buffers doesn't make too much difference. Just > keep the buffers full and sound will be fine.
But in the end, there's really no way to know, right? From what I gather, jack can add another buffer and report on it, but it's the sound card buffer that determines whether there are problems or not, right? I suppose using jack and real-time gives you extra assurance that the sound card buffer is being served as necessary. Using jack without real-time wouldn't provide any more assurance than a setup without jack, would it? - Grant > Keep in mind that Jack offers additional features which aren't of > primary interest to you, such as mixing audio from multiple apps, > adding dithering and other things, but what I think is of interest is > that Jack TELLS you ACTIVELY if your application or system aren't > keeping up. Music playing apps in general don't do that so you have no > way to determine if the sound card ever had problems. This is reason > enough for me to use Jack *most* of the time. Unfortunately things > like audio from a web page doesn't integrate well in this model so my > machines all have two sound cards. I use a good quality RME card in > most machines as the primary Jack-enabled device, but I still use the > internal sound chip to hand system sounds, audio from browsers and > other stuff I'm not too worried about. I then send that audio into my > good card and deliver it to the RME which goes through external DACs > to my studio monitors. > > Hope this helps, > Mark
