Open-source USB interface: Audio Widget

[Turbon]

But I hate python...

Anyway, oscilloscope showed no sign of 12MHz - fixed - there was of course a short. Tried again on Linux and here is parts of the syslog from the time I press prog/reset and release the prog button.

---
Nov 24 13:42:46 Minty kernel: [ 7508.368096] usb 5-1: USB disconnect, address 32
Nov 24 13:42:48 Minty kernel: [ 7509.848042] usb 5-1: new full speed USB device using uhci_hcd and address 33
Nov 24 13:43:07 Minty kernel: [ 7529.200118] usb 5-1: USB disconnect, address 33
Nov 24 13:43:07 Minty kernel: [ 7529.440064] usb 5-1: new full speed USB device using uhci_hcd and address 34
Nov 24 13:43:07 Minty kernel: [ 7529.560075] usb 5-1: device descriptor read/64, error -71
Nov 24 13:43:08 Minty kernel: [ 7529.784046] usb 5-1: device descriptor read/64, error -71
Nov 24 13:43:08 Minty kernel: [ 7530.000051] usb 5-1: new full speed USB device using uhci_hcd and address 35
Nov 24 13:43:08 Minty kernel: [ 7530.120097] usb 5-1: device descriptor read/64, error -71
Nov 24 13:43:08 Minty kernel: [ 7530.344059] usb 5-1: device descriptor read/64, error -71
Nov 24 13:43:08 Minty kernel: [ 7530.560046] usb 5-1: new full speed USB device using uhci_hcd and address 36
Nov 24 13:43:09 Minty kernel: [ 7530.972086] usb 5-1: device not accepting address 36, error -71
Nov 24 13:43:09 Minty kernel: [ 7531.084064] usb 5-1: new full speed USB device using uhci_hcd and address 37
Nov 24 13:43:09 Minty kernel: [ 7531.492080] usb 5-1: device not accepting address 37, error -71
Nov 24 13:43:09 Minty kernel: [ 7531.492105] hub 5-0:1.0: unable to enumerate USB device on port 1

----
Obviously there is a problem with the card...

Alex, you asked earlier for the full output from progwidget - that was the full output...

What about the physical USB ports? On this cheap Emachines E510 there is 3 USB ports 2 on the left and one on the right side. How would I know if they support "High speed"? In the control panel of vista there were a bunch of ordinary USB's and only 2 USB2 devices.

Now, I believe we have put enough focus on this one so I have ordered a tested and functional box from Borges (ship it fast Börge)... This one will be saved until the next time I feel to fix it. Thanks a lot for all the efforts you have put into it. Eventually I hope to post a note when it is working.

Brgds

 

[alexlee188]

Hi Turbon:

1. It is a good idea to order a tested and functional AB1.1 from Borge
2. As for your Emachines E510, read the user manual etc.
3. Even if the PC port is only USB1.0, the audio-widget should enumerate and work (at 44.1/48khz)
4. After you have fixed the 12Mhz XO problem, have you tried to re-flash with dfu-programmer?
5. If the earlier dfu-programmer output was only those you posted, there was something wrong - the flashing got stuck at the "erase" stage.
6. Try re-flashing again.

Alex

 

[Turbon]

Yupp, it feels like a good idea but still it nags me that it won't work.
Yes, I will RTFM...
Yes, the latest output is after fixing the 12MHz.
Yes, I tried again...

Thanks a lot Alex but I don't think we come any further with this one. I will order a new MCU or two - it will probably work right out of da box.

Brgds

 

[alexlee188]

Hi all,

I just tested the PurePlayer software for playback under Windows:

http://www.purediy.gr/downloads/pureplayer.zip

The sound quality is excellent and there is no extraneous noise when skipping tracks with audio-widgets.

Alex

 

[Turbon]

Now I bought Borges AB-1.1 and it arrived today, after some initial fiddling with it these are my findings:

1: I have to feed it at the bottom of the wave volume control in XP so I have aout 3 steps to silence. I can live with this as long I can keep output below 2VRMS.

2: This one is nicer. Whatever flacs I throw on it of the selection I posess, it plays them without a hitch. With UAC-1 I'm not supposed to have anything above - now there is different views of if it is 24/48 or 24/96. Never mind - I have 24/192's from reiable sources - vlc becomes a bit slow responding but sound is good. I first believed it was my very old SB Live! from about year 2000 that pranked me - I disabled it and checked where the AB-1.1 was connected on the amp - no problem there. A double check was the oscilliscope and indeed there was signal out...
So might the old SB drivers give it a boost, not to native UAC-2 but allowing it to playback 24/192? I would really want to know where my scheme glitches...

Brgds

 

[UnixMan]

Nope, likely the system is downsampling the stream on the fly. That also explain why v;c becomes slow (resampling may take a lot of CPU).

 

[Turbon]

You are quite right UnixMan, thanks.

 

[alexlee188]

You will find different players will give you different sound quality under Windows.

There are many factors at play:

1. Whether resampling occurs. Best SQ comes from no resampling.
2. Player software should run at highest "real time" priority. Do not run any other programs/processes at the same time.
3. Best player software loads the whole song into RAM and play from RAM. Disk access -> noise.
4. Drivers and options - ASIO, kernel mode streaming etc. only applicable to certain third party drivers.

I have found PureAudio player to give the best SQ under Windows. (but still not as good as mpd under Linux).

You have to experiment and find out for yourself.

Alex

 

[alexlee188]

PurePlayer I mean - see earlier post.

 

[RocketScientist]

@alexlee188 I certainly agree with factor #1. I don't agree with #2 unless you have a really marginal PC and/or can hear dropouts, ticks, glitches, etc. And I'll perhaps agree with #3 if you're using motherboard audio or an internal sound card. #4 seems like the least understood aspect.

Many (most?) players are making the exact same calls to the exact same APIs. And as long as they're delivering a bit accurate stream (i.e. no DSP, resampling, etc.) you'll get exactly the same sound (i.e. via DirectSound in Windows).

I have a USB protocol analyzer. It captures the actual packets being sent to an external USB DAC. And, guess what, it doesn't matter if I use Windows Media Player, Foobar, Media Monkey, VLC or my own custom software players. The exact same data gets sent to the DAC in Windows 7 with the volume set to maximum. And, by definition, that means all the players sound the same. I'm not saying some players don't screw things up somehow, but I can attest the ones listed above all deliver the same bits.

It would be interesting to repeat that test for Linux and OS X. I would expect the same results. That is, after all, what "bit accurate playback" is all about.

I would suggest the differences many claim to hear are either due to different settings, or they're just the usual well documented differences our brains serve up in sighted listening tests even when no differences really exist.

 

[abraxalito]

Many (most?) players are making the exact same calls to the exact same APIs. And as long as they're delivering a bit accurate stream (i.e. no DSP, resampling, etc.) you'll get exactly the same sound (i.e. via DirectSound in Windows).

You'll get the same bits, but the same sound? Some evidence supporting this claim would be nice to see. After all, no sound comes out of the computer itself, the sound is dependent on a whole host of supporting equipment.

I would suggest the differences many claim to hear are either due to different settings, or they're just the usual well documented differences our brains serve up in sighted listening tests even when no differences really exist.

How are you going to test your hypothesis?

 

[alexlee188]

1. Even in USB soundcards, noise from the PC gets to the sound card via the power supply leads. Good filtering helps but unless u have full opto-isolation, some PC noise will feed through. Granted, the noise feedthrough though measurable with a scope, is often not audible.

2. It is good that you have actually looked at the USB bits transferred from PC to USB soundcard. But were those measurements done with up to 192khz/24bit async out with rate feedback with different buffer sizes in the drivers? Some of us have heard differences in SQ just with different driver buffer size settings.

I agree that listening tests are subjective. But theoretical arguments and measurements can also be misleading.

Look back at the debate about SQ between solid state and tube amplifiers. You can measure the THD and argue that since solid states have 0.000001% THD MUST sound better than vacuum tubes with 0.1% THD !!! But does THD tell the whole story?

Alex

 

[RocketScientist]

Alexlee188 & Abraxalito, I don't want to de-rail this thread with OT discussion of tube amplifiers, etc. But bits are bits and if the external equipment remains the same (i.e. the USB DAC) those bits will deliver the same result every time if they're the same bits. If anyone has a plausible explanation as to how that's not the case, please share it?

My USB captures were all garden variety UAC1 isochronous playing normal 44 Khz CD audio at 16 or 24 bits which should cover about 98% of people playing music on a USB DAC. Short of dropouts if it's too small, and latency (which doesn't effect SQ), the buffer size won't make any difference either.

I don't think there's anything misleading in what I'm trying to say. Even the hard drive noise in the USB power is a rather extreme stretch, especially for a DAC like my Benchmark DAC1 that doesn't even use the USB power for anything.

I also have a full ABX box and it should be possible to set up a blind test with 2 players at a time and compare them. If they're delivering the same bits, I can promise nobody will be able to tell them apart. In fact I'll bet money on it.

 

[abraxalito]

ABut bits are bits and if the external equipment remains the same (i.e. the USB DAC) those bits will deliver the same result every time if they're the same bits. If anyone has a plausible explanation as to how that's not the case, please share it?

That's the wrong way around. Science is done by the one who makes the claim supporting it, not the naysayers spending their time shooting down unsupported assertions.

 

[rsdio]

bits are bits and if the external equipment remains the same (i.e. the USB DAC) those bits will deliver the same result every time if they're the same bits. If anyone has a plausible explanation as to how that's not the case, please share it?

My USB captures were all garden variety UAC1 isochronous playing normal 44 Khz CD audio at 16 or 24 bits which should cover about 98% of people playing music on a USB DAC.

Digital audio channels are two dimensional: they incorporate instantaneous values with timing of those samples. If the same bits are delivered, it doesn't guarantee that the timing of the conversions is identical, and thus you can have significant and measurable noise by merely the effect of clock errors.

Therefore, the only case in which your "identical bits" claim is valid is where the USB DAC is the master clock. Otherwise, there could easily be variables.

It may be worth pointing out that all UAC transfers are isochronous. That's the only option for UAC. Where the options come in are asynchronous, synchronous, and adaptive. Asynchronous is the one you want, because it does not depend upon the USB for clock, so all you need is that the computer keep up with sending the data. Some folks may be happy with SPDIF or USB synchronous or adaptive, but there are certainly more variables there which are dependent upon the computer that hosts the USB.

 

[RocketScientist]

@rsdio, isn't it the USB hardware in the PC that determines the timing of the USB data? So regardless of what mode the USB DAC is using to generate MCLK, the USB timing from a given port on a given PC is fixed.

Put another way, the player software is, through various API's and layers within the OS and driver, simply keeping a hardware buffer reasonably full and the USB hardware in the PC is then shipping off the bits in a very independent fashion. It's in no way related to the CPU clock or the load on the load on the CPU. It's just an independent chunk of hardware emptying a buffer. The only way the software can have any influence is to let the buffer run empty.

The only variable alexlee188 was talking about changing is the player software. Nobody has explained how player software can alter the timing of the USB hardware PHY in the PC? The software can alter the bits being sent, which is why I used the USB analyzer to look at the packets and verify it really is the same data.

So same data, sent with the same timing, by the same hardware, to the same hardware, equals same sound in my book. I completely agree different DACs can interpret the same bits differently due to jitter issues. And I agree different PCs/USB ports can send the data with more or less jitter. But we're just talking about comparing software here.

 

[abraxalito]

So same data, sent with the same timing, by the same hardware, to the same hardware, equals same sound in my book.

Thanks for clarifying that its just your opinion.

 

[borges]

Steady on the wheel guys! We're trying to trust both our ears and our scientific knowledge of analog and digital systems here. There are so many gopher holes to step into. Power, clocking, IV conversion etc. Getting the bits correctly through the hose is just one of them. We welcome both analog and digital hackers here. Personally, I believe every single subsystem has potential for improvement. Please direct "digital is flawed", "transistors are flawed" etc. elsewhere. I can explain for an hour why there is an audible difference between SPDIF cables. But I choose not to do it here.

If you wonna be constructive, feel free to buy a kit from George or from myself, change the output filter, mod the PSU, install a battery, or build your own Analog Board from scratch. In short - go nuts. But please do it constructively.

The _results_ of true blind tests of different players would be very welcome.

Børge

 

[RocketScientist]

I'm trying to be constructive. Myths are propagated by posts such as alexlee188's. It's useful to explain what really matters, what doesn't, and why. There's a lot of confusion about how USB audio really works and this thread is about USB DACs. It's useful to know the software, short of being bit accurate, doesn't matter for sound quality with a USB DAC of any sort.

To put it another way, there's no way for software to alter the timing of the data going out the USB port in anything resembling a predictable way. And if that's true, there's no way the bright guys behind Foobar can design their software for any better sound quality than the ones behind PurePlayer.

 

[abraxalito]

I'm trying to be constructive. Myths are propagated by posts such as alexlee188's.

And your 'there's no sound difference if the bits are the same' claim doesn't pass muster as a myth? Shurely shome mishtake.

To put it another way, there's no way for software to alter the timing of the data going out the USB port in anything resembling a predictable way. And if that's true, there's no way the bright guys behind Foobar can design their software for any better sound quality than the ones behind PurePlayer.

In async USB (which is what this thread's about) there's no way for the software to alter the timing at all at the DAC end.