Hi Starn,
Which firmware version is this with? Are you on a version with the new USB PIDs?
Is your computer very busy? Does it help to give the player a higher priority?
Do you have the same problems on 44.1*2^n as on 48*2^n? These two frequencies are generated by independant crystal oscillators which may have different relative deviation compared to your PC's clock. (See below for why this is important.)
Are you able to get an exact reading of the oscillator (MCLK) frequencies in both 44.1 and 48 modes? A frequency counter with 4 digits is required.
Actually, I'd like to focus on the UAC1 issues in MacOS first. But it is interesting that this happens on your computer, because on all the computers where I have tested the bug fix the noise has gone away.
Heres is an explanation of what causes the noise.
What happens is that the PC for some reason misses a feedback message which tells it to speed up or calm down its data transfer. There are two buffers in the firmware, one which is being filled by the USB task and another which is played back to the I2S interface. There is one fill pointer and one drain pointer. The "distance" between them is being monitored.
The playback is synchronous with the audio stream while the USB operates in burst mode. When a feedback message is missed, the PC's frequency drifts too far, and the same buffer is temporarily used for both data filling from USB and playback to I2S. It's the drifting into the same buffer which causes the noise to appear gradually.
Because there is one burst mode transfer and one continuous transfer, the fill pointer and drain pointer will cross each other multiple times, typically once for each USB packet.
What you will hear then is old (previous USB packet) and new (latest USB packet) audio being multiplexed in the time domain. When the feedback is functional, only the previous packet shoudl be played back, and the buffers should have some slack. Having no slack will generate a lot of bursts in the audio signal.
The noise finally ends when the difference in fill frequency (PC side) and drain frequency (DAC side) has caused the firmware data pointers to drift further apart than a complete USB packet's worth of audio data. Then, or after a little more drifting, the feedback system will kick back into gear and once again tell the PC to speed up or calm down.
The old code in UAC2 mode works like a thermostat with a single upper bound and lower bound for the discrepancy between the fill and drain pointers. That caused the error you are describing on multiple computers. What I did was change it to four thresholds. That solved it on numerous tests. It may be that this algorithm needs even more patching. Given the coarseness allowed in the adjusting (+-64), we're very far from a functional PID regulator. My attempted bug fix was to take it from a thermostat to a 4-level P regulator.
On all the PCs I have tested the the four-threshold firmware, the revised algorithm cleaned up the noise issue. But it may be that your particular combination of computer and XO has a large discrepancy in relative frequency.
This is interesting! I'll see what I can come up with and it would be very interesting to try to optimize this on your computer.
Børge
Which firmware version is this with? Are you on a version with the new USB PIDs?
Is your computer very busy? Does it help to give the player a higher priority?
Do you have the same problems on 44.1*2^n as on 48*2^n? These two frequencies are generated by independant crystal oscillators which may have different relative deviation compared to your PC's clock. (See below for why this is important.)
Are you able to get an exact reading of the oscillator (MCLK) frequencies in both 44.1 and 48 modes? A frequency counter with 4 digits is required.
Actually, I'd like to focus on the UAC1 issues in MacOS first. But it is interesting that this happens on your computer, because on all the computers where I have tested the bug fix the noise has gone away.
Heres is an explanation of what causes the noise.
What happens is that the PC for some reason misses a feedback message which tells it to speed up or calm down its data transfer. There are two buffers in the firmware, one which is being filled by the USB task and another which is played back to the I2S interface. There is one fill pointer and one drain pointer. The "distance" between them is being monitored.
The playback is synchronous with the audio stream while the USB operates in burst mode. When a feedback message is missed, the PC's frequency drifts too far, and the same buffer is temporarily used for both data filling from USB and playback to I2S. It's the drifting into the same buffer which causes the noise to appear gradually.
Because there is one burst mode transfer and one continuous transfer, the fill pointer and drain pointer will cross each other multiple times, typically once for each USB packet.
What you will hear then is old (previous USB packet) and new (latest USB packet) audio being multiplexed in the time domain. When the feedback is functional, only the previous packet shoudl be played back, and the buffers should have some slack. Having no slack will generate a lot of bursts in the audio signal.
The noise finally ends when the difference in fill frequency (PC side) and drain frequency (DAC side) has caused the firmware data pointers to drift further apart than a complete USB packet's worth of audio data. Then, or after a little more drifting, the feedback system will kick back into gear and once again tell the PC to speed up or calm down.
The old code in UAC2 mode works like a thermostat with a single upper bound and lower bound for the discrepancy between the fill and drain pointers. That caused the error you are describing on multiple computers. What I did was change it to four thresholds. That solved it on numerous tests. It may be that this algorithm needs even more patching. Given the coarseness allowed in the adjusting (+-64), we're very far from a functional PID regulator. My attempted bug fix was to take it from a thermostat to a 4-level P regulator.
On all the PCs I have tested the the four-threshold firmware, the revised algorithm cleaned up the noise issue. But it may be that your particular combination of computer and XO has a large discrepancy in relative frequency.
This is interesting! I'll see what I can come up with and it would be very interesting to try to optimize this on your computer.
Børge
The time bar pull has a different fix. It relates to clearing the LSB of the buffer pointer when the USB write start. That is the bug which I found in UAC2 and also fixed in UAC1.
It's very valuable that you have the same error on two drivers!
The /8 part is because there are L and R samples, each is 32 bit. That's 8 bytes. I don't think it's the endpoint size (512 bytes in AVR32) which matters but rather the number of transferred bytes.
With Nikolay's driver I did a long-time test of this, and the number of bytes was always n*8.
Are you able to populate the RS232 amplifier on the DAC? Then you can monitor debug messages which I put into the code.
Børge
Hi Borges, than you for your detailed explanation.
I can confirm that the clocks are OK (checked by scope) and that the problem happens at 44.1 and 48.
I followed your explanation, I agree with your analysis. Maybe we can think of a different scheme for the buffers: after all, even if the endpoint memory is limited, we can have more buffers in RAM (to be used by the DMA), given also that the samples are taken byte by byte from the buffer (this is another question I have, why not align the buffers to 32 bit and use a function to extract 32 bits in one shot).
As regards the "load" on the computer ... the computer has plenty of power, only a few percent is used ... moreover the problem happens at least on 3 notebooks I have, completely different ones ...
Finally: is it possible, someway, to "detect" when a packet is lost and force a realignment (maybe a short gap in playback?
I can confirm that the clocks are OK (checked by scope) and that the problem happens at 44.1 and 48.
I followed your explanation, I agree with your analysis. Maybe we can think of a different scheme for the buffers: after all, even if the endpoint memory is limited, we can have more buffers in RAM (to be used by the DMA), given also that the samples are taken byte by byte from the buffer (this is another question I have, why not align the buffers to 32 bit and use a function to extract 32 bits in one shot).
As regards the "load" on the computer ... the computer has plenty of power, only a few percent is used ... moreover the problem happens at least on 3 notebooks I have, completely different ones ...
Finally: is it possible, someway, to "detect" when a packet is lost and force a realignment (maybe a short gap in playback?
The code that does this in UAC2 is in uac2_device_audio_task.c at line 212 and onwards.
I'm curious why this happens on your kit and not on a lot of others. Let me know if you're able to insert the RS232 amplifier and connector. Then we can compare debug messages. There may be multiple places where things go haywire in your system.
Having longer fifos or buffers will only help so much. The problem occurs when the two pointers drift closer than the number of samples in one USB package.
Børge
I'm curious why this happens on your kit and not on a lot of others. Let me know if you're able to insert the RS232 amplifier and connector. Then we can compare debug messages. There may be multiple places where things go haywire in your system.
Having longer fifos or buffers will only help so much. The problem occurs when the two pointers drift closer than the number of samples in one USB package.
Børge
Hi Starn,
Your setup is the only one I have heard of which still has this kind of problem after fw upgrade. Could you help me debug it? I can send you an RS232 amp which is easily strapped to the module so that you can view debug messages in a terminal emulator. You'll have to solder in 4 wires. Write me an email and we'll figure out the details.
Børge
Your setup is the only one I have heard of which still has this kind of problem after fw upgrade. Could you help me debug it? I can send you an RS232 amp which is easily strapped to the module so that you can view debug messages in a terminal emulator. You'll have to solder in 4 wires. Write me an email and we'll figure out the details.
Børge
hi there
he's not alone in this... under UAC2 in linux when listening to 96/192kHz tracks i get this metallic sound for about a second or two. sometimes is on the start of the track... sometimes is when you change the track
i didn't write about this "problem" here because i'm not a forum guy
he's not alone in this... under UAC2 in linux when listening to 96/192kHz tracks i get this metallic sound for about a second or two. sometimes is on the start of the track... sometimes is when you change the track
i didn't write about this "problem" here because i'm not a forum guy
Hi, you must use audio_widget_20121004_AB-1.2.elf - sdr-widget - AB-1.2 firmware - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
or later firmware or later. If noise persists with this version (and later), let me know.
Børge
or later firmware or later. If noise persists with this version (and later), let me know.
Børge
audio widget 1.1 problems in mac osx 96k
hello
i use my AG 1.1 in mac osx at 192khz in UAC2, thats sound great, but i discovered that it don't work at 96khz, when you try to play at this sample rate, you have distorted audio and sound disappear gradually till silence in several seconds.
when this happend, red led on cpu pcb lights on as soon as you press play
i tried several firmwares, and i discovered that just some firms produce this problem:
audio-widget-ex-2012-08-13.elf
audio_widget_20120919.elf
audio_widget_ex_20120912.elf
this others versions that i tested works fine:
audio-widget-20120428.elf
audio-widget_20120721.elf
i tested this sample rates: 44.1, 48, 96, 192
the frecuencies between 96 and 192 don't work in any firm, and i think that is unsuported, due to the sound, that is very different to the 96k noise (and is not necessary, in my opinion).
if is usefull, i can record and post the noise
thank you
juanjo
hello
i use my AG 1.1 in mac osx at 192khz in UAC2, thats sound great, but i discovered that it don't work at 96khz, when you try to play at this sample rate, you have distorted audio and sound disappear gradually till silence in several seconds.
when this happend, red led on cpu pcb lights on as soon as you press play
i tried several firmwares, and i discovered that just some firms produce this problem:
audio-widget-ex-2012-08-13.elf
audio_widget_20120919.elf
audio_widget_ex_20120912.elf
this others versions that i tested works fine:
audio-widget-20120428.elf
audio-widget_20120721.elf
i tested this sample rates: 44.1, 48, 96, 192
the frecuencies between 96 and 192 don't work in any firm, and i think that is unsuported, due to the sound, that is very different to the 96k noise (and is not necessary, in my opinion).
if is usefull, i can record and post the noise
thank you
juanjo
Hi All,
in my case, all versions of firmware work the same way (metallic sounds on all fw).
Only the latest version of audio_widget_20121004_AB-1.2.elf sounds different.
Is significantly more silent at 192/24 (UAC2) and only at this sample rates appears metallic sounds.
My OS: Linux, kernel: 3.2.0-32-generic x86_64
Zumbik
That's strange. I never had a problem on Linux (with just about any firmware version since long time ago), except when (by accident) I did set a wrong configuration via the "widget_control" GUI. Could you post a screen shot of "widget_control"? (immediately after start-up, without changing anything)
Currently I have firmware audio_widget_20121004_AB-1.2.elf
However, this problem still exists.
Screen shot of the widget (with windows). In attachment...
Is it possible to check this on the linux console without @#% M$ ?
I have only one high-priority processes: my player (XBMC)
USB connected devices:
Code:
root@music:~# lsusb
Bus 001 Device 002: ID 16d0:075d GrauTec
Bus 005 Device 002: ID 0403:c630 Future Technology Devices International, Ltd lcd2usb interface
Bus 005 Device 003: ID 0bc7:0006 X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant)Today I will look into this problem on mpd player without xbmc.bin process
Attachments
Yes, there is a widget control program for Linux (and other systems, too). Though it will not work on the console. You'll need an X11 display (*).
It's the one written in Python: "WidgetControl.py" and related files. Download them from the git repository:
Po_SWR_board_beta.JPG
WidgetControl.py
WidgetControl.rsrc.py
Save these three files in the same dir, leaving the file names exactly as they are, including capitalization.
The main program is "WidgetControl.py". Make it executable: "chmod +rx WidgetControl.py".
"WidgetControl.rsrc.py" is a library used by the main program; the other file is an image which is used by the GUI.
To make it work you'll need a working Python installation with some extra libraries. You'll need the "PythonCard", "wx" and "usb" modules.
On a recent Debian system, these are the package that must be installed:
python
python-pythoncard
python-usb
python-wxgtk2.8 ( or python-wxgtk2.6 )
python-wxversion
pythoncard
pythoncard-tools
(on other distributions/versions the package names may be different).
That is, if you use Debian or a derived system (such as Voyage, and perhaps also *Ubuntu, etc) you may give the command:
Code:
apt-get install pythoncard python-usbEdit:
(*) P.S.: Børge, Alex et all: it would be a nice idea to write a CLI version of the tool (no GUI/TUI) which may be used from the command line on any console, and useable also from a script!
Last edited:
Thank you UnixMan, great FAQ.
Long time I was looking for appropriate distribution for my project... I have Ubuntu installed with mini.iso, also I have an X11 installed, XBMC needs this.
My hardware:
I started on the Intel Atom DualCore DN2800MT Mini ITX, but finished with AMD Dual-Core Zacate E350 APU.
But back to my problem ... I could not find a solution.
In this particular 192/24 album, I have five files. Three of them act badly in the linux os.
MPD did not even reads these "broken".
XBMC as on youtube, but what is strange, Windows 7 64 + foobar2000 reads all without any problem.
Completely can not understand why this happens.
It is the only 192/24 album I have, so I do not able to make more tests
Long time I was looking for appropriate distribution for my project... I have Ubuntu installed with mini.iso, also I have an X11 installed, XBMC needs this.
My hardware:
I started on the Intel Atom DualCore DN2800MT Mini ITX, but finished with AMD Dual-Core Zacate E350 APU.
But back to my problem ... I could not find a solution.
In this particular 192/24 album, I have five files. Three of them act badly in the linux os.
MPD did not even reads these "broken".
XBMC as on youtube, but what is strange, Windows 7 64 + foobar2000 reads all without any problem.
Completely can not understand why this happens.
It is the only 192/24 album I have, so I do not able to make more tests
well, this is suspicious. May be they are somehow corrupted? Which format are they?
Try to convert them to another format, e.g to decompress to wav files if they are compressed, or compress them if they are uncompressed (of course using a lossless codec such as flac).
You may use "flac", WavPack (files .wv), "mac" (monkeys-audio, files .ape), etc. Or you may also use tools such as shntool or SoX.
You may also want to open them with some audio editor such as Audacity and check the spectrograms, etc.
BTW: you say you are using Ubuntu: do you have properly configured PulseAudio or completely removed (uninstalled) it?
Last edited:
Oh! Interesting, thanks. I missed that one.
Is it up-to-date with recent firmware changes?