[wilsynet]

What is your background here?

I have a degree in Computer Science, have been working in Silicon Valley for the past 10 years.  I've worked on things like operating system and application provisioning, video games, networking devices, network appliances.  Currently, I run a ~100 person software engineering team at a well respected, late stage Silicon Valley startup.

Having said that, I'll be the first to admit that my specialization is not audio or audio processing.  My core specialization is networking.  As I was saying before, I've made some speculation as to why more memory can make a difference and I cannot prove it.  Certainly I cannot prove it without looking more deeply into the issue than I have.

But at the end of the day it's the same thing, the driver converts the data to PCM stores it in system memory and the DMA controller for the USB device will push the data to the USB DAC.

No dispute that DMA transfers occur between the device and the memory where the audio stream is written.

You seem to be a bit of an audio expert as it comes to systems and software, so perhaps you could answer some lingering questions.

One of the features that these audiophile targeted music players claim is Hog Mode.  That is, exclusive access is granted by the device driver to the application.  When I play music, even when not in Hog Mode, I'm not playing some other music by some other application at the same time.  But regardless of whether there is another active application contending for the device, Hog Mode sounds better anyway.

The only rational explanation I could think of (again, without doing quite a bit of experimentation, the time I don't have because the job keeps me pretty busy) was that Hog Mode makes the data transfer from user space programs and libraries to kernel space to system bus, finally to the device more efficient. 

There's likely a bunch of code in the kernel which is skipped because the device is in Hog Mode.  And if "skipping the execution of code" results in better sound, then presumably less contention on the CPU and less contention on the system bus overall is also likely to result in better sound.

Anyway, seems like you're an expert, so perhaps you could help me resolve that question as to why Hog Mode seems to sound better.

[skunark]

You seem to be a bit of an audio expert as it comes to systems and software, so perhaps you could answer some lingering questions.

My background as a EE has been focused on architecture, logic design, validation and implementation, lately architecture and design.  As a hardware engineer, you learn quickly that how the design was architected normally isn't how software utilizes it.  

One of the features that these audiophile targeted music players claim is Hog Mode.  That is, exclusive access is granted by the device driver to the application.  When I play music, even when not in Hog Mode, I'm not playing some other music by some other application at the same time.  But regardless of whether there is another active application contending for the device, Hog Mode sounds better anyway.

The only rational explanation I could think of (again, without doing quite a bit of experimentation, the time I don't have because the job keeps me pretty busy) was that Hog Mode makes the data transfer from user space programs and libraries to kernel space to system bus, finally to the device more efficient. 

There's likely a bunch of code in the kernel which is skipped because the device is in Hog Mode.  And if "skipping the execution of code" results in better sound, then presumably less contention on the CPU and less contention on the system bus overall is also likely to result in better sound.

Anyway, seems like you're an expert, so perhaps you could help me resolve that question as to why Hog Mode seems to sound better.

Since I don't have a pc/mac connected attached to my stereo, I haven't heard the difference with Hog Mode to become a believer, but I've been trying to understand that as well, to me Hog Mode would actually make other processes swap a bit more increasing traffic on the system bus impacting the very thing hog mode is suppose to avoid.  But if the only media application is running, then it's really not going to matter as it takes quite a bit to saturate the system bus.   I can see how Hog Mode can improve cache coherency for the application, but that still won't impact jitter as the dma controller will fill the buffer long before it underflows.  If you make the assumption that file will be decoded to system memory consistently (which I hope is true), once the application/driver updates dma descripters, the cpu is now off the hook and the dma controller takes over.  This really isolates the CPU and OS from the downstream device, so I'm just not seeing how hog mode could influence the quality of the sound.   

If I every decide to drop in a quality sound card in my Mac Pro, then perhaps I will experiment with it but I'm rather happy with using the Bryston BDP-1.  It's pretty barebones linux setup with not much going on in the background with just apache, samba, few random perl scripts and the mpd running.   
 

   

[wilsynet]

As I was saying before, don't think underflow has anything to do with jitter. Anyway, it seems like neither one of us have anything more useful to add because while you understand hardware in the general sense, and I understand software in the general sense, neither one of us have sufficient expertise in how (say) Mac OS X Core Audio Hog Mode is written or how (say) Pure Music is optimized.

[skunark]

At the lowest level, packet/audio block jitter would be the mechanism that the system bus, memory or even the CPU can influence on playback.   An underflow is the the only way I can see impacting the sound card.  Right?  It's not realistic to see the data be moved a bit at a time especially when the processor will do at least a byte if not a cache-line.    SPDIF jitter will be influenced by the packet jitter (multiple bytes) and also the oscillator(each rising and falling edge) along with any other downstream artifact.  USB will have a few more obstacles, but the ischochronous packets holds a millisecond of audio data, which again isolates the OS and application from influencing at the edge level. 


Fun thing about all of this is that Benchmark's website shows how to configure the popular players (with no plugins) to get bit perfect playback.   I'm guessing that is the end goal here.   

[JohnR]

I would have thought the end goal to be accurate reconstruction of the analog signal. To that end, the sample rate conversion and dithering features seem pretty cool to me

[wilsynet]

It's not realistic to see the data be moved a bit at a time especially when the processor will do at least a byte if not a cacheline.  SPDIF jitter will be influnced by the packet jitter (multiple bytes) and also the oscillator(each rising and falling edge) along with any other downstream artifact.

Okay, actually this resonates with me.  I'm with you.