Alex:
I just tried the new version. No help with 44.1 chain files. I got it to screw up once on a 48K chain transition from 96 to 192 but I could not get it to happen twice.
Now I'm getting a shift from 44.1 to 48 when its not supposed to happen, in the midst of an 88.2 file the pitch jumps up. Listening to Rebecca Pidgeon shifting keys that way is unsettling. I will revert.
Except for the obvious the audio seems to be as good.
I just tried the new version. No help with 44.1 chain files. I got it to screw up once on a 48K chain transition from 96 to 192 but I could not get it to happen twice.
Now I'm getting a shift from 44.1 to 48 when its not supposed to happen, in the midst of an 88.2 file the pitch jumps up. Listening to Rebecca Pidgeon shifting keys that way is unsettling. I will revert.
Except for the obvious the audio seems to be as good.
Problems still. This is wat is reported when switching froma 44.1 to an 88.2 file:
cygnus:~# cat /proc/asound/card1/stream0
Objective Development DG8SAQ-I2C at usb-0000:00:0f.5-1, high speed : USB Audio
Playback:
Status: Running
Interface = 2
Altset = 1
URBs = 8 [ 8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 171383 Hz (0x15.6c40)
Feedback Format = 16.16
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
And after pause then play:
Playback:
Status: Running
Interface = 2
Altset = 1
URBs = 8 [ 8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 88195 Hz (0xb.0640)
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
It seems the feedback format is getting borked or some such.
I also get a sort of quick buzz hitting pause or stop from 88.2.
cygnus:~# cat /proc/asound/card1/stream0
Objective Development DG8SAQ-I2C at usb-0000:00:0f.5-1, high speed : USB Audio
Playback:
Status: Running
Interface = 2
Altset = 1
URBs = 8 [ 8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 171383 Hz (0x15.6c40)
Feedback Format = 16.16
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
And after pause then play:
Playback:
Status: Running
Interface = 2
Altset = 1
URBs = 8 [ 8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 88195 Hz (0xb.0640)
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
It seems the feedback format is getting borked or some such.
I also get a sort of quick buzz hitting pause or stop from 88.2.
More testing and more details:
I put togehter a playlist with 6 sample rates and 44.1 at 16 and 24 bit depth. everything else is 24 bit depth.
pause, stop and switching will produce a pop or a momentary buzz.
88.2 has problems and will often start at 177 it seems.
It sound very good otherwise. I think there is some stress in the upper ranges I can't pin down. Switching firmware is pretty disruptive making comparisons difficult.
I put togehter a playlist with 6 sample rates and 44.1 at 16 and 24 bit depth. everything else is 24 bit depth.
pause, stop and switching will produce a pop or a momentary buzz.
88.2 has problems and will often start at 177 it seems.
It sound very good otherwise. I think there is some stress in the upper ranges I can't pin down. Switching firmware is pretty disruptive making comparisons difficult.
Hi Demian,
The watchdog only checks for switch to 96/192 currently. 88.2/176.4 are NOT watched
If u want I will add the code to watch those sampling rates as well.
Looks like this switching has caused side effects:
1. Playback software changes playback stream sampling rate unannounced
2. Widget firmware watchdog switches freq
3. Uac2 driver is caught unawares as neither playback software nor device firmware inform of freq switch
4. Uac2 driver confused. Suddenly the feedback rate is doubled from 44.1 to 88.2. The drivers automatic rate feedback format algorithm thinks format ha changed from 16.16 to 17.15. So for a while driver and firmware are out if rate feedback sync.
5. Hence pop:noise and other nasties.
So perhaps it is time to fix mpd rather than to try to force the poor watchdog to do all the dirty work
Alex
The watchdog only checks for switch to 96/192 currently. 88.2/176.4 are NOT watched
If u want I will add the code to watch those sampling rates as well.
Looks like this switching has caused side effects:
1. Playback software changes playback stream sampling rate unannounced
2. Widget firmware watchdog switches freq
3. Uac2 driver is caught unawares as neither playback software nor device firmware inform of freq switch
4. Uac2 driver confused. Suddenly the feedback rate is doubled from 44.1 to 88.2. The drivers automatic rate feedback format algorithm thinks format ha changed from 16.16 to 17.15. So for a while driver and firmware are out if rate feedback sync.
5. Hence pop:noise and other nasties.
So perhaps it is time to fix mpd rather than to try to force the poor watchdog to do all the dirty work
Alex
Hi Demian,
Try this:
audio-widget-nik-2012-01-21.elf - sdr-widget - Unified firmware for audio-wdgets. Watchdog switches sampling rate to 88.2/176.4/96/192 if incoming rate changes unannounced. This is a workaround for mpd. If you use PurePlayer and other "well behaved"
Turbon,
If you are using PurePlayer you don't need this fix. This is to fix a problem with mpd.
Alex
Try this:
audio-widget-nik-2012-01-21.elf - sdr-widget - Unified firmware for audio-wdgets. Watchdog switches sampling rate to 88.2/176.4/96/192 if incoming rate changes unannounced. This is a workaround for mpd. If you use PurePlayer and other "well behaved"
Turbon,
If you are using PurePlayer you don't need this fix. This is to fix a problem with mpd.
Alex
An externally hosted image should be here but it was not working when we last tested it.
Red: WinXP-Foobar2000-SoX48 UAC1
Purple: Linux-44100 UAC2 Voyage Music Player
This is an excellent measure in Linux. It has taken me to get it because first I reproduced the WAB file from a old USB stick and it was pretty bad old measure. Now from another new USB stick measured very well.
Since Foobar2000 configured to play from memory and oversampling to 48,000 improvement.
I do not know, in Linux MPD server, how to configure a resamplig and a memory playback from a WAV file.
192000 resampling is even better. Playing the file from memory may be better.
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?
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?
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.
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.
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.
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.
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.
An externally hosted image should be here but it was not working when we last tested it.
All the same level in dB.
An externally hosted image should be here but it was not working when we last tested it.
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.
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.
Last edited:
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.
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.
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
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
Hi,
I have a Q.
During playback (16/44.1 stuff) this is my stream0:
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
I have a Q.
During playback (16/44.1 stuff) this is my stream0:
Code:
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 usSo, 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