Open-source USB interface: Audio Widget

[Onvinyl]

Originally Posted by oneoclock

192000 resampling is even better. Playing the file from memory may be better.

AFAIK mpd can't do that.
Pity!

[1audio]

Your results look excellent and very similar to mine. What are you using as a capture system?

You can configure mpd to resample to a higher frequency but there are several "gotchas" in doing that. You will need to install the sox package to get the resamplers and then configure them in the mpd.conf file. The best resapling options use a lot of cpu. They will most likely crash on an Alix (Geode 500 MHz) and I have had problems on an Atom.

Also, one of the values of the AB1.1 is the operation at the native sample rate. Usually a good dac will sound better when given the raw data instead of reprocessed data from a resampling or other process. The ESS runs at 512 fs internally I think for 44.1 and 48. Since its running synchronously in this implementation it should be as clean as any resampling process.

MPD's default setting loads 10% of the file when it starts and the OS will probably load the rest in the the local disk cache if you have enough ram. Loading more usually doesn't help and slows down mpd's response to commands. What platform are you running Voyage MPD on?

[1audio]

Here is more on the internal settings on mpd's buffers: Details of MPD internal buffering. Its probably not worth fiddling. I'm looking for more details on the Linux disk caching processes but have not found a lot, just indications that Linux will use all the available memory.

[1audio]

Alex:
Progress I think but not fixed. Going from 44.1 to 88.2 it goes to 96K. Pause then play gets it back. At 96K the rate feedback suggests everything is perfect (this is for an 88.2 .wav file):


Playback:
Status: Running
Interface = 2
Altset = 1
URBs = 8 [ 8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 96000 Hz (0xc.0000)
Feedback Format = 15.17
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 2 OUT (ASYNC)
Rates: 44100, 88200, 132300, 176400, 48000, 96000, 144000, 192000
Data packet interval: 250 us
Rebecca is singing flawlessly at full tone higher it seems.

I can't duplicate this on Windows, but the Windows apps I have tried all take a long time to switch tracks so I'm not sure if there isn't some other stuff going on.

I tried playing in Linux using "aplay". (No mpd involved) With aplay if I play a 44.1 wav file stop and then play an 88.2 wave file it plays the 88.2 at 96. Stop and play the 88.2 file again and it works. 48 to 96 works perfectly. In 48 and 96 the momentary frequency is always perfect. It never is in 44.1 rates. Is this because the 44.1 do not divide into the 1KHz communications rates?

Using the command line I get an ugly buzz/burp for a moment when stopping the stream.

[oneoclock]

I tried 4 cards:

Pink: M-Audio FastTrak Pro
Blue: Tascam US-144
Green: Motu Ultralite mk3
Yellow: RME Fireface

I think the best measure is the Motu, and RME similar.



All the same level in dB.

[oneoclock]

I have a Linux boot image MPD Voyage on a flash drive. On a Celeron 3.2 Gb 1 Gb RAM.

When read the first time file WAB, pendrive have flashes. But successive reproductions not blink because it must be in RAM and have better measures.

Linux MPD 44100 is better than MAC iTunes 44100.
But WinXP-Foobar2000-SoX-48000 is better than Linux MPD 44100

My best measures I think are MAC with iTunes and PureMusic Resampling to 192000.

Yellow RME Fireface graphic is MAC with iTunes and PureMusic Resampling to 192000.

The rest are Linux MPD 44100.

[1audio]

Normally adding the resampling will confuse the jitter measurements. They are usually made with the tones precise sub-multiples of the sample rate to remove the effects of the DAC not switching on a sample. With a submultiple of the sample rate all of the dac values will be the same. If you are using a 48K sample rate you should create a file with a 48K tone. A square wave removes any issues from the sine passing through zero. I have several interesting test files. I'll try compressing them to see if they are still really big.

Supposedly the width of the base of the primary tone is an indication of the close in phase noise of the clock system. It would be both the generator (AB1.1) and the analyzer so its possible they both contribute. By that measure the RME and the Motu seem to be the best.

I'm not sure that testing a sampled system with a sampled system is not hiding something, but I don't have the bandwidth to test in an alternate way, using a swept spectrum analyzer etc.

[alexlee188]

Hi Demian,

Thanks for your tests and reports with the watchdog -> unannounced sample rate change firmware.

I have done some more tests myself here and I am beginning to think that the problem is NOT unannounced sample rate change.

As you have reported previously, the problem occurs only when changing tracks from low to high sampling rates, but never from high to low sampling rates. Also stopping and restarting the track will cure the "wrong" sampling rate.

By the watchdog changing the sampling rate to match the incoming USB rate, alsa driver seems to be confused and the rate feedback goes haywire (may have something to do with alsa's uac2 driver automatic detection of rate feedback format).

So it looks like it is a much more complex interaction between player software, alsa uac2 driver, and widget firmware.

I will continue to comb through the widget firmware to check for possible bugs. But if the problem is in mpd or in alsa uac2 driver, I can't fix that by changing the firmware along :-)

So for the time being revert back to the previous generation of firmware:

audio-widget-nik-2012-01-15.elf - sdr-widget - Unified firmware for audio-wdgets. Tweaked uac1_audio FB_RATE_DELTA param. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting

and don't play mixed tracks for the time being :-)

Alex

[Onvinyl]

Hi,
I have a Q.

During playback (16/44.1 stuff) this is my stream0:

cat /proc/asound/card1/stream0
www.obdev.at DG8SAQ-I2C at usb-0000:00:13.2-2, high speed : USB Audio

Playback:
  Status: Running
    Interface = 2
    Altset = 1
    URBs = 2 [ 7 7 ]
    Packet Size = 392
    Momentary freq = 44109 Hz (0x5.8380)
    Feedback Format = 15.17
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 2 OUT (ASYNC)
    Rates: 44100, 88200, 132300, 176400, 48000, 96000, 144000, 192000
    Data packet interval: 250 us

So, the playback freq is slightly off. Is this due to the async-thingy or is something wrong? This is not limited to the use of mpd.

Rüdiger

[Turbon]

Hi all.

Could someone please reveal the settings for the exprimental uac2 win driver since I need to listen to it and try to figure out its inner workings. Please pm me or email through my nick.

Thanks and Brgds