I thought you talked about SPDIF.
I analyzed length of isochronous adaptive URBs in linux usb-audio stack and never could detect any deviation from the optimal (best-case) count of samples in each frame. On USB 1 it was always 48 samples in each 1ms frame for 48kHz, and 9 x 44 + 1 x 45 samples for 44.1kHz. Cannot get any better
The only (hardly controllable) effect software can have is noise on power lines.
On USB 1 it was always 48 samples in each 1ms frame for 48kHz, and 9 x 44 + 1 x 45 samples for 44.1kHz. Cannot get any better
But did you use a spectrum analyser to look for jitter on the sampling clock at 1/440 of the sampling rate?
The problem is in the soundcard hardware where it has to transform the uneven flow of data at 44.1kHz into a steady word clock. Some PLL in there has to reject the cyclic variation between 44 and 45 sample frames while tracking drift in the computer's clock. A software-only analysis won't reveal any of this.But did you use a spectrum analyser to look for jitter on the sampling clock at 1/440 of the sampling rate?
No, but how could software improve on that? 9x44 + 1x45 is the most-steady/continuous flow of the 44.1kHz stream on the 12MHz USB1 bus, causing least work for the PLL.
In my experience, audio playback on Linux with MPD and ALSA has always been hassle free. If you could test the USB stack on Windows, it might be a different story.
There is also the real-time issue of whether the USB packets are sent exactly on time. The computer has to send exactly 1000 frames per second to the DAC, any variation will be jitter that has to be rejected by the PLL. TI had a large white paper on the technology they developed to do this in their USB 1.1 audio receivers.
CPU loading could potentially disrupt the frame rate. I imagine it is mostly done by DMA, but even the DMA will need reloading now and again.
The audio problems I've found have always been gross buffer overruns.
There is also the real-time issue of whether the USB packets are sent exactly on time. The computer has to send exactly 1000 frames per second to the DAC, any variation will be jitter that has to be rejected by the PLL. TI had a large white paper on the technology they developed to do this in their USB 1.1 audio receivers.
CPU loading could potentially disrupt the frame rate. I imagine it is mostly done by DMA, but even the DMA will need reloading now and again.
The audio problems I've found have always been gross buffer overruns.
Of course my analysis was done on linux (wireshark). But I doubt windows should be any different.
No, the timing is controlled by the USB controller, reading data from RAM via DMA. The CPU does not influence the timing in any way. DMA runs independently of CPU copying new samples into RAM. If the controller hits a frame marked as "throw IRQ", it just throws an IRQ "hey I have just transfered this particular frame". In linux these frames mark end of URB (group of frames processed by the kernel in one round). Of course while the IRQ is being thrown/serviced, the USB controller continues transferring data read from RAM via DMA to the soundcard.
Unless it runs out of data because the CPU got sidetracked and allowed the DMA buffer chain to run empty. To be fair, this would probably result in an obvious click, pop or glitch rather than some subtle jitter. As far as I know it is the most common failure mode in USB audio. No desktop OS is hard real-time, therefore none of them can guarantee to always fill up the DMA on time.
Proving that if USB adaptive audio is free of obvious glitches, it is also free of audible jitter, is left as an exercise for the reader.
Right, that would cause an audible pop/glitch and would be reported as an xrun in linux alsa. Of course such situation is a common problem, nothing exotic.
Jitter can be influenced by SW only indirectly, by varying power load = noise on supply lines. I very much doubt anyone has ever succeeded in controlling this impact in a predictable way. Even though lots of closed-source snake oil claim to do so.
Jitter can be influenced by SW only indirectly, by varying power load = noise on supply lines. I very much doubt anyone has ever succeeded in controlling this impact in a predictable way. Even though lots of closed-source snake oil claim to do so.
So, are you asserting this to be true? Nothing can go wrong with adaptive audio except xruns? This seems reasonable, but computers are so complicated I wouldn't have the confidence to say such a thing without a lot of testing.
No.
Linux is a time-consuming nightmare that wastes weeks of time and has fans that do nothing but make excuses.
I will never again waste another second attempting to get any Linux distro of any flavour installed on any of my machines, ever again.
My mind is permanently closed on this matter.
Last edited:
Ah, good to hear that there are sound, rational reasons. It is true that Linux does require a bit of understanding and technical knowledge.
What Phofman said, plus 1
Installing Precise Puppy + Deadbeef through ALSA (bit-perfect) + any USB (including Xmos) DAC will not take more than 25-30 minutes, (Including downloads
), it has a total of 20-25 Processes (and 8 Threads, ALL audio related) running WHILE decoding 24bit/384Khz FLAC with a CPU load less than 2% on dual core Celeron, Uhmm, did I mention that it's FREE and it is still a computer?
Last edited:
Easily done.
I do not have a soundcard my feed goes through the player, ASIO, then out the USB port to a dedicated DAC that sits outside the music server.
There is nothing to configure.
ASIO pulls the stream out from the various mixers and volume controls, rendering them inoperative.
Not to miragem3i anymore, but to the general audience who wants to use brain.
A USB DAC is a USB soundcard. Vast majority of USB sound devices offer a list of controls. Muting, volume control, switching outputs, SPDIF preamble format, some can offer switching SPDIF input as clock source, etc. Of course a windows user has no idea they even exist. In linux all that is needed is running
amixer -c CARD_NAME
A PCI soundcard many people still use offers many controls too. Typically Juli@, infrasonic quartet, xonar, they all offer control elements important for advanced (power) users. Some of them are available in the GUI screens provided by the manufacturer.
Again, hard-core audiophiles use DACs with clock output and slave their Juli@s to this SPDIF feed. How can this be configured in a cut-down windows install like this is beyond my understanding. Clearly proponents of such ideal setups do not care either.
Nonsense, ASIO can convey those controls, provided they are offered by the driver. Which is often not the case, since it takes work to code for the driver author. These controls are not what built-in windows audio setup screens offer.
A USB DAC is a USB soundcard. Vast majority of USB sound devices offer a list of controls. Muting, volume control, switching outputs, SPDIF preamble format, some can offer switching SPDIF input as clock source, etc. Of course a windows user has no idea they even exist. In linux all that is needed is running
amixer -c CARD_NAME
A PCI soundcard many people still use offers many controls too. Typically Juli@, infrasonic quartet, xonar, they all offer control elements important for advanced (power) users. Some of them are available in the GUI screens provided by the manufacturer.
Again, hard-core audiophiles use DACs with clock output and slave their Juli@s to this SPDIF feed. How can this be configured in a cut-down windows install like this is beyond my understanding. Clearly proponents of such ideal setups do not care either.
Nonsense, ASIO can convey those controls, provided they are offered by the driver. Which is often not the case, since it takes work to code for the driver author. These controls are not what built-in windows audio setup screens offer.
We might have reading comprehension issues, but someone has Linux hating issues.
FWIW, there are difficult and fiddly flavours of Linux out there. For example, I tried VoyageMPD and Audiophile Linux and could not get either to work. Audiophile Linux has the worst install procedure of any OS or software I have ever seen in my entire life. VoyageMPD simply didn't support my network card and I gave up figuring out how to add a driver for it.
FWIW, there are difficult and fiddly flavours of Linux out there. For example, I tried VoyageMPD and Audiophile Linux and could not get either to work. Audiophile Linux has the worst install procedure of any OS or software I have ever seen in my entire life. VoyageMPD simply didn't support my network card and I gave up figuring out how to add a driver for it.
I've been working on this machine:
It is a Pentium II Celeron 333Mhz with 320 Mbytes of RAM and 8 Gb HD. It is running MPD 0.18.x on Ubuntu 14.04 Server Minimal Install and I can manage it using SSH and my cell phone can handle the MPD interface .
This pile of crap wasn't able to run W2K without a lot of swap, and now it is wirelessly connected to my home network and it can play music without any swap at all (don't ask me about the sound card I'm using, because it is even older than the PC... it is a SB AWE-64 ).
More info here...
Yep.... I love Linux.... and it took about a couple of hours to complete...
It is a Pentium II Celeron 333Mhz
with 320 Mbytes of RAM and 8 Gb HD. It is running MPD 0.18.x on Ubuntu 14.04 Server Minimal Install and I can manage it using SSH and my cell phone can handle the MPD interface .This pile of crap wasn't able to run W2K without a lot of swap, and now it is wirelessly connected to my home network and it can play music without any swap at all (don't ask me about the sound card I'm using, because it is even older
than the PC... it is a SB AWE-64 ).More info here...
Yep.... I love Linux.... and it took about a couple of hours to complete...
Attachments
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.