B4B
Hey Daniel,
I totally agree bandwidth-wise audio is a trivial task for just about any subsystem in a modern PC. Heck, in a PC optimized for it, a modern PC can handle the combined digital bandwidth of 32 tracks of audio acquisition simultaneously as seen in ProTools setups I have done. However, attempts to do this on a similar general purpose PC running the usual suite of apps shows limitations due to something happening in hardware or software.
So my experience says raw bandwidth and speed of PC subsystems does not equate to keeping audio buffers full in many PCs. Especially if one is listening to a file on USB or network storage, limitations in some aspect of PC audio data handling can cause buffer depletion. My brother's i5/8GB laptop is a good example, it certainly has a capable CPU and RAM. However in actual daily use it would appear that the stock audio player thread execution is of a lower priority than video memory servicing (or something). With the stock Microsoft ASIO audio device driver, when he is watching a HD video with an audio file playing simultaneously, the audio will stutter. With the JPLAY driver configured for several seconds of buffer this does not happen.
I lack the low-level PC diagnostic tools to analyze exactly what priority and amount of CPU time each program running on a PC uses, but I can infer from my experience at work and professionally that many PCs have poor audio performance due to one or more of a few factors:
CPU/memory bandwidth limitations.
Excess latency due to OS handshaking calls to hardware hanging up subsystems waiting for response.
Thread priority not optimal for audio and a lot of threads of higher priority.
I apologize for my ignorance of the exact cause of what I observe; without advanced debugging tools or digital PC architecture knowledge there is little way to see what is happening with audio in PCs...makes one appreciate the simplicity of a hardware CD player or analog TT!!!
Cheers!
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
Howie,
Any OS that allows buffer underruns for audio is in a pathological state on a modern computer. And by modern I mean ~pentium IV era computing.It's not like audio is at all demanding data wise.
D
Hey Daniel,
I totally agree bandwidth-wise audio is a trivial task for just about any subsystem in a modern PC. Heck, in a PC optimized for it, a modern PC can handle the combined digital bandwidth of 32 tracks of audio acquisition simultaneously as seen in ProTools setups I have done. However, attempts to do this on a similar general purpose PC running the usual suite of apps shows limitations due to something happening in hardware or software.
So my experience says raw bandwidth and speed of PC subsystems does not equate to keeping audio buffers full in many PCs. Especially if one is listening to a file on USB or network storage, limitations in some aspect of PC audio data handling can cause buffer depletion. My brother's i5/8GB laptop is a good example, it certainly has a capable CPU and RAM. However in actual daily use it would appear that the stock audio player thread execution is of a lower priority than video memory servicing (or something). With the stock Microsoft ASIO audio device driver, when he is watching a HD video with an audio file playing simultaneously, the audio will stutter. With the JPLAY driver configured for several seconds of buffer this does not happen.
I lack the low-level PC diagnostic tools to analyze exactly what priority and amount of CPU time each program running on a PC uses, but I can infer from my experience at work and professionally that many PCs have poor audio performance due to one or more of a few factors:
CPU/memory bandwidth limitations.
Excess latency due to OS handshaking calls to hardware hanging up subsystems waiting for response.
Thread priority not optimal for audio and a lot of threads of higher priority.
I apologize for my ignorance of the exact cause of what I observe; without advanced debugging tools or digital PC architecture knowledge there is little way to see what is happening with audio in PCs...makes one appreciate the simplicity of a hardware CD player or analog TT!!!
Cheers!
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
It does, just abstracted into the allocated memory blocks given by the OS. (Of course you're probably just teasing, but this is just knee jerk reaction to teaching this stuff previously )
Edit: the only time we try to talk to directly-directly talk to a specific memory block (rather than by a reference pointer from the OS) is in some rather specialized embedded software where you are the OS, too. Not stuff I've done for work, but certainly stuff I've tortured students with.
)Edit: the only time we try to talk to directly-directly talk to a specific memory block (rather than by a reference pointer from the OS) is in some rather specialized embedded software where you are the OS, too. Not stuff I've done for work, but certainly stuff I've tortured students with.
Last edited:
B4B
Thank you for the correction Jan! It shows how antiquated my knowledge of programming is. I remember learning some C years ago before object oriented programming when one had to explicitly make a memory management call to create a chunk to use...but I guess that is now done behind the scenes? And what actually transpires after compiling is something else...
Cheers!
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
Thank you for the correction Jan! It shows how antiquated my knowledge of programming is. I remember learning some C years ago before object oriented programming when one had to explicitly make a memory management call to create a chunk to use...but I guess that is now done behind the scenes? And what actually transpires after compiling is something else...
Cheers!
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
Howie, that sounds a lot like driver issues. In either case, I'm going to be *very* surprised to see incidental latency issues cropping up on the uptake from data source, versus the prioritization on the outputs side.
And certainly NOT going to manifest in *sounding different*. It's going to be pauses or not pauses.
Which is to say, we're agreeing.
And certainly NOT going to manifest in *sounding different*. It's going to be pauses or not pauses.
Which is to say, we're agreeing.
It does, just abstracted into the allocated memory blocks. (Of course you're probably just teasing, but this is just knee jerk reaction to teaching this stuff previously
How about self modifying code. The MAC allowed you to generate instructions as an array of hex numbers and cast the pointer to it as a function pointer and execute it.
Howie, that sounds a lot like driver issues. In either case, I'm going to be *very* surprised to see incidental latency issues cropping up on the uptake from data source, versus the prioritization on the outputs side.
And certainly NOT going to manifest in *sounding different*. It's going to be pauses or not pauses.
Which is to say, we're agreeing.
You can bring a powerful DAW (Digital Audio Workstation) to it's knees by loading it up with tracks, VST plugins, and setting the ASIO buffer size small for low latency. However, you are right that it starts stuttering or something of that nature, not changing the how the music sounds in more subtle ways.
Yeah, I think we're talking about different issues, my apologies. The original claim was that an already-compiled audio track sounded different being loaded from different storage media. That's about as easy a data task as they come. The demands of a DAW are a bit different, when you're running any number of poorly optimized filters simultaneously.
B4B
Thanks Daniel, I'm glad to hear from folks with more knowledge of the subject! This is a very interesting phenomenon, I have worked on PCs with poor audio playback such as weird 'echoes' which I determined to be just repeats of previous audio frames, as well as the symptoms you and I observed like muting or gaps, but also player UI hanging when playing USB files. Installing a different player would sometimes cure the symptom. This indicates to me even using the stock Microsoft driver different players act differently when encountering difficulty with timely data streaming...or something...I really hate saying "something," but I just do not have the tools or knowledge to diagnose the issue other than trying different pieces of the puzzle like changing players, drivers, or configuring settings in these two.
Yes, it sure is great to have an improved driver like JPLAY to diagnose and fix driver issues, but I can't tell you what the differences in data error handling between Microsoft Media Player, Winamp, Foobar2K and dBPowerAmp would be. These players can sometimes act differently when encountering "something" (grrrr) in the way of streaming data.
Ah well, I can always listen to an 8-track, and as long as I hear a "Kerchunk!" at regular intervals I know all is well with playback...ain't analog great!
Cheers!
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
Howie, that sounds a lot like driver issues. In either case, I'm going to be *very* surprised to see incidental latency issues cropping up on the uptake from data source, versus the prioritization on the outputs side.
And certainly NOT going to manifest in *sounding different*. It's going to be pauses or not pauses.
Which is to say, we're agreeing.
Thanks Daniel, I'm glad to hear from folks with more knowledge of the subject! This is a very interesting phenomenon, I have worked on PCs with poor audio playback such as weird 'echoes' which I determined to be just repeats of previous audio frames, as well as the symptoms you and I observed like muting or gaps, but also player UI hanging when playing USB files. Installing a different player would sometimes cure the symptom. This indicates to me even using the stock Microsoft driver different players act differently when encountering difficulty with timely data streaming...or something...I really hate saying "something," but I just do not have the tools or knowledge to diagnose the issue other than trying different pieces of the puzzle like changing players, drivers, or configuring settings in these two.
Yes, it sure is great to have an improved driver like JPLAY to diagnose and fix driver issues, but I can't tell you what the differences in data error handling between Microsoft Media Player, Winamp, Foobar2K and dBPowerAmp would be. These players can sometimes act differently when encountering "something" (grrrr) in the way of streaming data.
Ah well, I can always listen to an 8-track, and as long as I hear a "Kerchunk!" at regular intervals I know all is well with playback...ain't analog great!
Cheers!
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
I haven't done much of that, but I know roughly how to write self-modifying code in C by breaking out into an assembly block. You can take the pointers still from outside the assembly block and manipulate them appropriately, IIRC.
There is something called "Data Execution Protection" now. If enabled, it prevents areas of memory marked as containing data from being executed as instructions.
Howie, "something" does unfortunately become a major force, especially when we're not neck deep in the code. FdW and Jan probably have a better grasp than I do, but we're at the mercy of somewhat byzantine audio workflow (that has changed with OS revisions and muddled the landscape further)
D
D
Last edited:
B4B
And my comment on the original issue was only that one cannot equate B4B results to streaming behavior. The only way I have ever heard the same file sound different from different sources is with odd gaps, stutters, audio frame repeats, etc. This thread has morphed into what can cause different playback issues with different players/drivers. Sorry if I was the cause of thread drift, I'm trying to do work I dislike (building units for sale, don't ask what units, please...) and that is causing me to pay too much attention to the DIY forum. Scott, you were right, I shoulda kept quiet!
Back to *sigh* work,
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
And my comment on the original issue was only that one cannot equate B4B results to streaming behavior. The only way I have ever heard the same file sound different from different sources is with odd gaps, stutters, audio frame repeats, etc. This thread has morphed into what can cause different playback issues with different players/drivers. Sorry if I was the cause of thread drift, I'm trying to do work I dislike (building units for sale, don't ask what units, please...) and that is causing me to pay too much attention to the DIY forum. Scott, you were right, I shoulda kept quiet!
Back to *sigh* work,
Howie
Howard Hoyt
CE - WXYC-FM 89.3
UNC Chapel Hill, NC
WXYC Chapel Hill, North Carolina - 89.3 FM
Probably for the better, BTW I noticed last night I missed a nice conversation you had with chris on the ASIO, exclusive/shared mode, etc. stuff while I was on vacation. I certainly respect your considered inputs on this but still find the app developers don't behave. I was trying some of the Octave audio capture functions after reading the latest Linear Audio. 24 bit returned garbage with all settings possible on my Scarlett 2i2, shared, exclusive, nothing mattered. The article sticks with 16/44.1 for good reason.
I guess pointer arithmetic does not work anymore?
It will [work], virtually then, even a .net language as c# can do pointer arithmetic, and it functions, even dough the whole environment, in that run-time, is virtual. The .net environment virtualizes all, the computer, the I/O, the memory, the files and even the file-formats (nothing escapes {see Tron}), this way the future may change but the computer keeps on functioning (virtually speaking then)
And may the force be with you [all]. O.k., now I'm going over the top.
Last edited:
Howie, that sounds a lot like driver issues. In either case, I'm going to be *very* surprised to see incidental latency issues cropping up on the uptake from data source, versus the prioritization on the outputs side.
And certainly NOT going to manifest in *sounding different*. It's going to be pauses or not pauses.
Which is to say, we're agreeing.
My experience is that its mostly misbehaving drivers as well. Usually drivers that are essential. The audio chain passes the audio data to a driver to pass to the hardware. that driver most likely uses a DMA transfer to load a circular buffer (or two) that in turn are passed to the card, again in bursts. USB has a lot more overhead than PCI. PCIE has a little overhead since its a serial link but should still be very small.
What I see mostly is an occasional dropped sample. The easiest way to see this is a long FFT. Everything looks as expected then suddenly the noise floor jumps 30 dB and the averaging needs to start over. Its completely random and maybe a single sample lost this way will be inaudible except possibly as a click. Linux is better than Windows but you can still have underruns on a busy system. Its much easier to troubleshoot on Linux however.
ASIO doesn't cure this but it does route around the Windows audio system. On Pyrimix the system locks one processor just for the DAW. I'm not sure what magic foo they do to grab a processor core, I think Windows would have issues but they have this working. Its really expensive and the DSP is all done in an outboard card running Phillips DSP's as I remember. But you can directly edit DSD supposedly with it.
I'll stick with Linux for troublefree audio playback.
Not quite correct.
I'm saying the following examples...
A: - Twice transfer a file to a player device (Android phone) using two different USB-A to USB-Micro data cables.
B: - Twice transfer a file to a USB Thumb drive using two different USB-A to USB-A extension data cables.
C: - Twice transfer a file to internal HD using two different USB-A to USB-A extension data cables (from external HD or Thumb Drive).
A: - Playback via 3.5mm line in socket of home shelf hifi or car hifi.
B: - Playback via USB socket of home shelf hifi or car hifi.
C: - Playback via Foobar using Laptop internal speakers or across network to Android Tablet connected to home hifi via 3.5mm or RCA input sockets.
Observations:
In all cases the two files (Treated, Non Treated) sound subtly but also significantly different.
First playback of either file is slightly different to immediate second playback of same file.
When changing files, second playback of new file and thereafter plays remain
unchanging.
It is as though there is some kind of embedded (quantum ?) information that retains in the (Treated) files that changes the behaviour of the playback system.....perhaps we have been dealing with this all along and have not realised...this could also be part explanation for 'burn in'.
Guys, I do know that these observations sound 'out there', but this is what I and others find, and reliably so enough to pass Blind Testing.
Right now I do not have proper explanation for these effects nor measurements, and all intelligent test methodologies suggestions are welcomed.
As I type I am totally rearranging my sunroom to be a precise test and measurement lab so I can flesh out details of what really is going on.
Dan.
I guess pointer arithmetic does not work anymore?
Of course it does, but the application has a virtual address space. Pointer arithmetic still works within the app, even though the OS and MMU may have moved the data around in physical memory or even swapped it out to disk.
PS I still haven't seen any CPUs with registers that hold "objects".
Edit: Oops I see there were multiple similar responses already
Last edited:
- Status
- Not open for further replies.