Jump to content
IGNORED

Just the facts: iTunes, lossless, AirTunes and jitter


kdoot
 Share

Recommended Posts

Hi all,

 

I lurk here a fair bit and post occasionally, and I need to have a go at setting something straight with regard technologies I understand pretty well. Here's what it boils down to:

 

If you use iTunes to rip your undamaged CDs to AIFF, WAV or Apple Lossless (ALAC), then you stream the music through an AirPort Express or Apple TV, what you get out of the optical interface is EXACTLY the same as the data on your original CD, REGARDLESS of which of the file formats you have saved the music in.

 

How can I be so confident? Because iTunes, the lossless file formats, the networking and the AirPort/AppleTV devices are all the product of an industry which has perfected the ability to store, transmit and reproduce digital data with perfect accuracy. Your music is just data, until the point it hits a DAC. (And frankly, it's a trivially small amount of data compared to what gets processed in the ordinary operation of a modern computer.)

 

Moreover, regardless of which lossless format you've saved your music in, iTunes ONLY TRANSMITS ALAC over the network, because that's the only data format the AirPort Express knows how to decode. If you save as WAV or AIFF, iTunes compresses using ALAC on-the-fly before it transmits. There really is NO difference in the final output.

 

MP3 and AAC change the outcome because they change the data. But the lossless formats are exactly that: without loss of information, regardless of which you use. The only thing that matters is how your DAC processes the perfect data it receives, and how tolerant it is of the tiny variations in signal timing we call "jitter".

 

On the subject of DAC sound quality and jitter tolerance, you are welcome to debate for all eternity. But please, no more claims that AIFF sounds better than ALAC when played through AirTunes. It just isn't possibly true.

 

(A special note for Peter of XXhighend: I acknowledge that your software techniques may result in jitter reduction for signals generated directly by a computer and its attached hardware, and that this may improve sound quality in DACs that are sensitive to jitter. I also acknowledge that the same principles may lead to variations in sound quality playing back different lossless formats using iTunes and a computer-based digital output. But this does not apply for lossless audio streamed to an AirPort Express or Apple TV.)

 

Thanks, and enjoy the music.

 

Link to comment
Share on other sites

One thing I was surprised to discover is that, for the AppleTV, regardless of whether you've disabled "control volume for music", the iPhone's Remote application will change the volume (and reset the setting) through the digital output. Normally that isn't an issue, but a careless touch of the volume control on the touchpad could start sending decimated digital data to your DAC. Not "bit perfect" at all. Just need to be careful, I guess.

 

But you're right about ALAC vs AIFF. Opening up Activity Monitor, the data rate streaming to the AppleTV doesn't change at all, even though the AIFF file is approximately double in size of the ALAC.

 

Link to comment
Share on other sites

"the networking and the AirPort/AppleTV devices are all the product of an industry which has perfected the ability to store, transmit and reproduce digital data with perfect accuracy"

 

Ummmm.... errrr.... might I respectfully direct your attention to:

http://www.computeraudiophile.com/content/Airport-Express-transmission-patchy

Perhaps the complete audio dropouts some of us regularly experience are just some kind of mass audiophilia-paranoia induced hallucination :D Probably induced by guilt at not spending ££££s on special cables and isolation cones.

 

Don't get me wrong here, I suspect I share your doubts about some of the claims made on behalf of different file formats etc etc. I'm interested in the discussion, but I rarely hear enough difference to affect my enjoyment of music I like, that's for sure.

 

But... software is far from being the clean precise perfectly optimised world that it might appear to be from the first principles of ones and zeros. It's often an assembly of one program black box of code bolted onto another, and I imagine it would be quite rare for one single developer to understand in entirety what is going on in the finished application they have worked on.

 

How easy do you think it would be to capture the output of an Airport Express to a file and then compare that to the original? Certainly I can understand that it would be possible to compare the data within ALAC / AIFF etc, and therefore verify that it's the exact same digital information (though frankly I've never bothered!), but I'm not so sure about capturing a digital audio stream from a toslink socket. Most of the assurances of bit-perfectness come from verifying that the output stream has the same frequency and word length as the original file (16/44 etc), which is surely only a partial confirmation, even without getting into discussions about the mysterious jitter.

 

Link to comment
Share on other sites

The dropouts you're describing have nothing to do with the encoding format of the source material or the amount of jitter in the output of the AirPort Express. This is not an audio quality concern - it's a network communications problem.

 

I actually have a similar issue with my own setup. I have to quit and relaunch iTunes more often than I'd care to because it will play the first ~20 secs or so of music and then just stop. (iTunes thinks it's still playing but nothing's being received by the AirPort Express.)

 

My point is that when the bits are received, they're the correct bits. Actually the dropout validates my point: you don't get random noise coming out because the AE *knows* it's not getting valid data.

 

Link to comment
Share on other sites

souptin...

 

I'm thinking about how to do the verification you suggested. Here's an idea, looking for feedback:

 

1. Start with a computer that has both optical out and in ports

2. Create an AIFF file from a track on CD

3. Connect an optical cable to the computer's out and in optical ports

4. Start recording from the optical input

5. Start playing the AIFF file to the optical output

 

The captured file becomes your baseline for comparison.

 

6. Convert the AIFF file to ALAC

7. Connect an AirPort Express optical out to the computer optical in

8. Start recording from the optical input

9. Start playing the ALAC file via iTunes to the AirPort Express

 

The second captured file shows what the AirPort Express would have sent to the DAC.

 

Compare the two files, trimming off the silence at the beginning.

 

Link to comment
Share on other sites

I agree with all your comments.

 

And the test, creating two waveforms is exactly what I wish to see from the likes of Sonic Studio to show us why Amarra is so special.

 

Come on Sonic Studio ... if you want us to buy your software, demonstrate to us why we should by it ....

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment
Share on other sites

I was thinking along the same lines.

 

Main difficulty I see would be to accurately trim out the start and end of your test track to the exact same point. I don't know audio editing software all that well, so it may be a little tricky to achieve this.

 

Also, you're quite right that the audio dropouts I talked about were not related to encoding. The reason I raised the issue is that I believe it illustrates that music streaming has different network requirements than file transfers.

 

Link to comment
Share on other sites

And the test, creating two waveforms is exactly what I wish to see from the likes of Sonic Studio to show us why Amarra is so special.

 

Come on Sonic Studio ... if you want us to buy your software, demonstrate to us why we should by it ....

 

Don't bother Sonic Studio, because in a bit perfect situation the files will be 100% equal and it proves nothing.

Of course it will prove the bit perfectness, which is as important. No, more.

 

 

 

Lush^3-e      Lush^2      Blaxius^2      Ethernet^2     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
Share on other sites

Also, you're quite right that the audio dropouts I talked about were not related to encoding. The reason I raised the issue is that I believe it illustrates that music streaming has different network requirements than file transfers.

 

Well yes... but only in a time-dependent sense. Streaming must deliver a certain amount of data in a certain time. File transfers aim to deliver all the data in the shortest possible time. Going slow doesn't break a file transfer, but it does break streaming.

 

In each case, though, the technology provides extremely high confidence that the bits delivered to the other end are actually the right bits.

 

Link to comment
Share on other sites

The point of Amarra appears to be that it *does* modify the data, but in the best-sounding way possible. The comparison graphs in http://www.sonicstudio.com/amarra/pdf/WhyAmarra.pdf show the audio effects of volume reduction using iTunes vs Amarra.

 

For those of us following the recommendations here at CA regarding bit-perfect playback from iTunes, Amarra software might offer no improvement in sound quality except perhaps through jitter-reduction techniques a la XXHighEnd.

 

Link to comment
Share on other sites

Kdoot

 

Hiya

 

I believe we have discussed those graphs before and agreed with the author they were not a fair comparison.

 

Will post the link when not on my iPod.

 

 

Matt

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment
Share on other sites

Peter

 

I don't see the harm in asking for a comparison. If I were interested then I would like to know where my money is going. Please explain why that is so unreasonable.

 

Computer audio opens up the world of high end without the need for high end pricing.

 

Matt.

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment
Share on other sites

I believe we have discussed those graphs before and agreed with the author they were not a fair comparison.

 

I believe you are reading only half of the posts, do not follow links, but do have an opinion which is, well, false. False is not so bad, but only when it can be recognized. Look what you are doing now : you are just telling someone that those graphs are not correct, while the real thing happening here is that you just don't know, or forgot.

 

Will you please look at those graphs now ?

They are perfectly allright, and a whole thread was spend on it.

 

Thanks,

Peter

 

PS: The graphs *were* not correct. But that's two weeks ago. :-)

 

Lush^3-e      Lush^2      Blaxius^2      Ethernet^2     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
Share on other sites

I don't see the harm in asking for a comparison. If I were interested then I would like to know where my money is going. Please explain why that is so unreasonable.

 

I don't want you to read this post as offensive (which might be nature, following my latest other posts in response to yours), but as "helping out", ok ?

 

You may recall a first expression from my hand, here at CA, that players sound different. I kind of accused you that you did not get this, and after a few posts back and forth you were the first to tell me "of course there is a difference". Like back then, and moreover in the context of today, I took that as a kind of defense, or copying my words if you want. The point for today is : this doesn't help you if you actually don't get it all that much. This is not an accusement or anything, and also this is not a negative. Because keep in mind : nobody understands. However, there is a difference between not understanding and not believing, while from the latter "statements" spring which are unjustified, and set people on the wrong track.

 

You may be willing to understand how some people may judge such "statements", if I refer to the XXHighEnd thread (yes, your thread), and someone named Tim started to tell he would be serious this time, and wanted to understand. However, some 50 posts later -when enough evidence in his eyes was collected- he started using that evidence in the most smart way he could think of, to make exactly those statements.

This is trolling. Besides that, it shows inconsistency all over. Why ? he couldn't understand.

 

Now on to your quote above;

 

If you yourself follow closeley what this question is about, include my response *and* know the basics at play here, you'd *know* the only thing coming from that is the proof of all being bit perfect.

Maybe you understand this better if I recall (especially for you) that the outcome of XXHighend would be the same : bit perfect. So would Foobar, Media Monkey and iTunes once people are able to dig up the proper settings.

 

Since you are asking the question, and do this in the context of your posts at CA here, we all might expect you understand (see the beginning of this post). Also, with some emphasize of voice (nah, 100 times more damped than the T/A combo) hundreds of people (of not way more) won't understand anymore, just because of your emphasis to the wrong things.

Moral : if you can't get it, don't make or imply statements.

 

So, back to my previous response, and the outlay which may help you in understanding :

 

If Amarra shows bit perfect playback, this is NO GOOD. It will help you zilch, because (nearly) everything can.

If Amarra does NOT show bit perfect playback, then everbody including you is helped a lot. Why ? because it proves that mangling with the data is going on, and this is WRONG. I mean, as you can imagine, a whole plethora of sound enhancements may be going on, and many many products can be bought for a few GBP just doing that job.

So, this was my response in telling that it actually *is* useful to let Amarra show it's bit perfect, but for the exact other reason. And btw, that showing of being bit perfect should be done under supervising of someone who also can judge the sound at that very moment. Thus, supposed Sonic would come up with some proof Amarra is bit perfect, will say nothing, because they shut off the equalizers, and the only thing happening is that now it is bit perfect, but may sound the same as iTunes (also being bit perfect).

 

So Matt, in the end your question is certainly reasonable, but not for your reasons.

 

Computer audio opens up the world of high end without the need for high end pricing.

 

Allow me to agree with this, although it would not be my subject. But of course this relates to me especially.

So I sure see your drive.

But now tell me, did you actually listen to Amarra (or Soundblade for that matter). I don't think so.

I did not either, but I think I behave neutral. But then of course I am more eligible to give a product like Amarra the benefit of the doubt, because I know what could have happened in there.

 

If I had a MAC you'd have my comparison months ago.

 

Kind regards,

Peter

 

Lush^3-e      Lush^2      Blaxius^2      Ethernet^2     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
Share on other sites

Peter,

 

Thanks for confirming that many software players are capable of outputting exactly the same bits that were originally read from the CD. That's a key point for me.

 

Please have another look at the Sonic Studio website, and I think you'll find that their product is quite explicit about modifying the audio data. For instance, those graphs we have referred to relate to the use of volume controls in iTunes and Amarra. Both modify the data, but Sonic claims that theirs does so in a way which more accurately preserves the original waveform.

 

So to summarize:

iTunes + AirPort Express = bit perfect from lossless files

XXHighEnd = bit perfect from lossless files + jitter reduction techniques

Amarra = complex data processing + specialised DAC hardware integration?

 

One of these days I'll try a comparison of iTunes and XXHighEnd into my DacMagic but for the time being I'm really happy with the sound and convenience of the AirPort Express. Except for the network drop-outs... :-

 

Link to comment
Share on other sites

Peter,

 

Quite a lot to reply to so I'll do it a bit at a time.

 

Firstly, you're correct to highlight my XX thread. Blindfold testing and comparing changed my opinions from back then. I could do some more testing but to me it sounds the same as iTunes via the Airport Express. The only difference there could be between the bit perfect outputs, could be jitter, which my DAC deals with. It can't be eliminated sure, but virtually and is not a problem.

 

Your statements regarding not understanding and not believing. My understanding is this, which seems to tie in with a number of other peoples views:

 

If a music player is outputting a file bit perfect, ie: the values are unchanged from those stored on the hard disk drive, then there cannot be any difference except perhaps jitter. This statement I believe to be correct. If the output timing is not uniform, it will be re-timed by, for example, the SPDIF interface to the DAC. The spdif interfaces can of course vary in their ability to do this. Jitter can then be introduced by the receiver, the clock recovery circuit and the DAC chip itself.

 

Given the above, and the fact my digital signal is reclocked, I should not hear a difference between XX and iTunes via the Airport Express. Both are bit perfect, both digital streams are reclocked.

 

Now I ask of you, do you *get this* ... I only ask in a polite sense of course because the above may be in complete disagreement to your own views.

 

Moral: do not assume people don't get it because their totally acceptable views are different from your own.

 

Kdoot has since corrected me regarding Amarra. The comparison to iTunes was completely unfair since it was converting the 24bit file to 16bit, very misleading. But it seems Amarra is not bit perfect as Sonic Studio choose to process the audio in order to improve sound quality. Whether that works or not I don't know. I guess this means the output may be different from the input.

 

Begs the question: can the output be better than the input then if it IS CHANGED ?.. the way they, Sonic Studio, change it may indeed mean it can. Maybe other users are hearing this from their pro audio editing software too.

 

 

Matt.

 

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment
Share on other sites

ps Peter,

 

No I've not listened to Amarra. I want them to come on here and tell us why it's so good.

 

At first, I wish for them to tell me how their bit perfect output could sound better to any other bit perfect output. Since it's not bit perfect it now makes sense - they're doing something with the audio that their expertise would allow them to do. To them it's better than bit perfect and that seems to be the case with those who have actually heard it.

 

How do you feel about data being changed? In my opinion this is the ONLY way there could be a difference, excluding jitter of couse, which I think for the most part with any decent DAC, is very nearly a non-issue.

 

 

Eeek Peter ... did you not just do the very thing you told me not to ? "mangling of data is wrong" "cheap products can do this" ... Sure Sonic Studio, professionals, would beg to differ.

 

 

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment
Share on other sites

 

Compare01a-33.png click to enlarge

 

 

Matt, when I referred to the link this is contained in at CA, you said "I see where you're getting at".

( http://www.computeraudiophile.com/content/Its-Friday-here-so-here-BIG-one )

 

This picture shows two bit perfect streams (I verified this by capturing it back and compare). One of the streams is the red line, the other one is the black. Apart from the pattern you see at the left halve (so both are not equal when looking at the DAC output which this is about, in the middle you see that suddenly all kinds of things happen to the black line. This is the point (in time) a cursor indicating the running time moves, and this repeats every one second, which is when the cursor moves ...

 

So what do you see here ? two bit perfect playbacks, the red line being the reference, the black line being different to that. Both is XXHighEnd; one is without GUI, and one is with (and that cursor of course).

 

I still have the hunch you missed this.

I'll be back later for your other questions.

 

Lush^3-e      Lush^2      Blaxius^2      Ethernet^2     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
Share on other sites

Peter wrote:

So what do you see here ? two bit perfect playbacks, the red line being the reference, the black line being different to that. Both is XXHighEnd; one is without GUI, and one is with (and that cursor of course).

 

So if I understand correctly, you played back a .wav file through your XXHighEnd program and the output of the DAC (what was the DAC device used?) was digitized using an ADC (again what device) - I assume feeding into a separate computer?

 

You did this twice, first using the GUI of XXHighEnd and then a second time using (I assume) a command line interface to XXHighEnd - sorry I don't know the XXHighEnd program and it's available interface so sorry if I'm incorrect.

 

Once you'd got the two DAC outputs digitized, then you used a audio editor to compare the two files? I'm assuming that you consider the CLI to provide a purer signal so use that as the reference (red) line? The black trace shows where there is a difference between the two signals?

 

Did you do anything to try to eliminate variations in how the ADC captured the data? What else did you do to ensure as level a playing field as possible. What operating system did you use.

 

You may have said all this when you posted the original graph (I suppose I should look at the link). If I sound like I'm doubting you then please forgive the tone, I'm just interested. To me, by itself one graph doesn't mean much ... you need to do tests of other applications to see how big a variation there is on them. How does iTunes look on a similar graph if you compare "bit-perfect" mode to using EQ enhancements and volume control for instance.

 

Thanks for the information so far.

Eloise

 

P.S. ... another thought ... could you run a similar test but play each sample (GUI and non-GUI) say 3 times and average the results; before them comparing it to each other. This would eliminate (most of) any external interference between the playback DAC and the measuring ADC.

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment
Share on other sites

....so here I am to confuse some more:)

 

 

iTunes puts out bit perfect when all settings are disable/maximized, Audio midi set to 1 or 100, Itunes volume set to max etc.

 

When comparing itunes to a CD player it should, I would assume, be a moot point that the comparision is when iTunes is set to bit perfect output. CD players, being what they are, normally only have one output, bit perfect maximum. Yes there are some with volume controls etc, but that's not the norm.

 

 

So I find it ironic that Amarra is comparing itself to iTunes in non-ideal conditions, i.e. non bit perfect mode.

 

I do feel that bit perfect is only the beginning of achieving the perfect music server. It's the pursuit of the other imperfections, jitter in its definable and indefinable terms, that keeps me on the path to improving my system.

 

I too, love the convenience and flexibility of my Airport Express, and it sounds pretty damn good feeding my EMU-0404USB. Dropouts? None. Mine's wired.

 

Maybe I should just throw in the towel and get a Zardoz:)

 

CD

 

 

Link to comment
Share on other sites

Audio_ELF, if you're really interested I'd encourage you to read the original thread, as well as the thread on Peter's forum linked off of the CA thread - this will save quite a lot of redundant discussion and explanation.

 

At this point I'm quite convinced that Peter is measuring real phenomena, although the exact causes of those phenomena are as yet undetermined (there are suspects, but no convictions). Informed speculation is welcome :)

 

Link to comment
Share on other sites

So if I understand correctly, you played back a .wav file through your XXHighEnd program and the output of the DAC (what was the DAC device used?) was digitized using an ADC (again what device) - I assume feeding into a separate computer?

 

In this example, yes, XXHighEnd. But it is unimportant.

The DAC, unimportant.

The ADC, same.

 

You did this twice, first using the GUI of XXHighEnd and then a second time using (I assume) a command line interface to XXHighEnd

 

Yes. On the matter of the command line, sort of, yes.

 

I'm assuming that you consider the CLI to provide a purer signal so use that as the reference (red) line? The black trace shows where there is a difference between the two signals?

 

CLI ? unimportant. This kind of test is not about "purer". It is about differences. About the black trace : correct.

 

Did you do anything to try to eliminate variations in how the ADC captured the data?

 

Not necessary. See more below.

 

What else did you do to ensure as level a playing field as possible.

 

Sorry, but this looks like chinese to me. Can't get it.

 

What operating system did you use.

 

Vista.

 

How does iTunes look on a similar graph if you compare "bit-perfect" mode to using EQ enhancements and volume control for instance.

 

I understand your question, but there can't be an answer to this.

This is about bit perfect against bit perfect, and what you propose is not in the first place.

I could show it, but it would be playing (toying). I am trying to be serious.

 

P.S. ... another thought ... could you run a similar test but play each sample (GUI and non-GUI) say 3 times and average the results; before them comparing it to each other. This would eliminate (most of) any external interference between the playback DAC and the measuring ADC.

 

Again I understand the question and the why of it, but it is not applicable. So :

Any number of subsequent runs of the same setting (of a player for that matter) give the same results and a "red line" only. So, no matter how wild it is (and the picture shows a pretty wild phenomenon) the results are exactly the same. For these kind of "relative tests" this eliminates the ADC and DAC for that matter. Or the OS, everything. Only the differences matter, and it is just those coming out.

When this were "absolute tests" the whole matter changes, and the answers should have been longer, and for sure more towards some skepticism, might you have it in the first place. On this matter, I am performing these absolute tests just the same, but indeed this is subject to the ADC in the first place. Much more difficult, but doable in the end.

 

I'm not finished with this.

 

Lastly :

 

Once you'd got the two DAC outputs digitized, then you used a audio editor to compare the two files?

 

No, it can't be as simple as that. I created my own analysis test suite in order to let this al work. It will be part of XXHighEnd for everybody's benefit.

Notice that this is about relative measurements in the first place, which can lead to absolute results with some knowledge and / or several different comparisons. What I showed is an example of that, the knowledge of that cursor leading to the better and the worse one. Now, with an absolute decent working of the ADC (or knowing the exact properties of it) absolute *reliable* measurements are possible. On that matter I will be working on the most accurate ADC (ever).

 

I hope this suffices for now, and I'm sorry to be a bit brief.

Peter

 

 

Lush^3-e      Lush^2      Blaxius^2      Ethernet^2     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
Share on other sites

 

Peter,

 

I'm reading with inerest and you have my attention.

 

Do you recall, or could you run the test again to find out CPU usage etc.? On running XX without the user interface are there any other processes running on the computer.

 

You can probably guess were I'm coming from already. I'm curious to see whether the unbroken waveform is produced as a result of NOTHING running, or whilst here are some processes running.

 

M.

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment
Share on other sites

BEEMB, as I understand it the graph does not actually show a waveform. It shows the difference between two waveforms from the same test file, at the same point in playback time, with different software settings. One waveform is arbitrarily chosen as the reference - that is the flat line. Any deviation from "flatness" in the other graph line indicates a difference in that waveform relative to the reference. The once-per-second "burst" in differences between the GUI vs. non-GUI waveforms strongly suggests that the difference is correlated to the screen refresh associated with updating the track time counter.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share



×
×
  • Create New...