Hi,
I've spent the last 18 hours in quest: where is the problem.
I conducted all tests on the linux and windows7 64, with FW audio-widget-2012-11-08 and awx_20121213
The same pc, only fresh linux. Here I described step, by step how I installed my linux. Description contains configs files. This text alive. Remember, everything can change ...
Now I know that the problem is with XBMC player when running at 192k, only. Other formats work correctly.
MPD player works fine in any format.
audio-widget-2012-11-08, Quirks = ----
awx_20121213, Quirks = none as default
* XBMC player. Some of the files works fine but not all.
** As above. However, there is a certain change. If I have a metallic sound, I press stop then restart plays, music play correctly.
*** Absolutely any 192k file plays correctly.
I've spent the last 18 hours in quest: where is the problem.
I conducted all tests on the linux and windows7 64, with FW audio-widget-2012-11-08 and awx_20121213
The same pc, only fresh linux. Here I described step, by step how I installed my linux. Description contains configs files. This text alive. Remember, everything can change ...
Now I know that the problem is with XBMC player when running at 192k, only. Other formats work correctly.
MPD player works fine in any format.
audio-widget-2012-11-08, Quirks = ----
Code:
UAC2 XBMC linux
44 ok
48 ok
88 ok
96 ok
176 ok
192 ERRORS, metalic sounds
Feedback Format = 7.17 & Format: S32_LE for all formats.
UAC2 MPD linux
44 ok
48 ok
88 ok
96 ok
176 ok
192 Ok [COLOR="Red"]***[/COLOR]
Feedback Format = 7.17 & Format: S32_LE for all formats.
-----------------------------------------
UAC1 XBMC linux
44 ok
48 ok
Feedback Format = 10.14 & Format: S24_3LE for all formats.
UAC1 MPD linux
44 ok
48 ok
Feedback Format = 10.14 & Format: S24_3LE for all formats.
--------------------------------
UAC1 foobar2k windows
44 cracks
48 cracks
UAC1 AIMP3 windows
44 cracks
48 cracks
--------------------------------
UAC2 foobar2k windows
44 ok
48 ok
88 ok
96 ok
176 ok
192 Ok
UAC2 AIMP3 windows
44 ok
48 ok
88 ok
96 ok
176 ok
192 Ok
Code:
UAC2 XBMC linux
44 ok
48 ok
88 ok
96 ok
176 ok
192 Is much better, but not perfect. [COLOR="red"]*[/COLOR]
192 (quirk_linux) as above [COLOR="red"]**[/COLOR]
192 (quirk_ptest) Format: S24_3LE ?
Feedback Format = 7.17 & Format: S32_LE for all formats.
UAC2 MPD linux
44 ok
48 ok
88 ok
96 ok
176 ok
192 ok - perfect!!! [COLOR="red"]***[/COLOR]
Feedback Format = 7.17 & Format: S32_LE for all formats.
-----------------------------------------
UAC1 XBMC linux
44 ok
48 ok
Feedback Format = 10.14 & Format: S24_3LE for all formats.
UAC1 MPD linux
44 ok
48 ok
Feedback Format = 10.14 & Format: S24_3LE for all formats.
--------------------------------
UAC1 foobar2k windows
44 cracks
48 cracks
UAC1 AIMP3 windows
44 cracks
48 cracks
--------------------------------
UAC2 foobar2k windows
44 ok
48 ok
88 metalic sounds
96 ok
176 ok
192 ok
UAC2 AIMP3 windows
44 ok
48 ok
88 metalic sounds
96 ok
176 ok
192 ok* XBMC player. Some of the files works fine but not all.
** As above. However, there is a certain change. If I have a metallic sound, I press stop then restart plays, music play correctly.
*** Absolutely any 192k file plays correctly.
Here is a firmware file for 16.16 UAC2 feedbac. It is tested on Windows and Linux on 44.1 and 192. This code is experimental. Please test it and let me know what works. My Mac purchase is taking longer time than predicted, so the FW is not tested on Mac. On Windows I have tested it with an updated version of Nikolay's ASIO driver, not with other ASIO drivers.
awx_20121222.zip
On Windows systems, close any ASIO player. Then make a backup of C:\Program Files (x86)\Audio-Widget\asiouac2.dll (or similar location) and replace it with the one from the zip file. If this works I'll package it into an installer.
This new build of asiouac2.dll supports both 15.17 and 16.16 feedback. All source code is commited to github.
Cheers,
Børge
awx_20121222.zip
On Windows systems, close any ASIO player. Then make a backup of C:\Program Files (x86)\Audio-Widget\asiouac2.dll (or similar location) and replace it with the one from the zip file. If this works I'll package it into an installer.
This new build of asiouac2.dll supports both 15.17 and 16.16 feedback. All source code is commited to github.
Cheers,
Børge
Wow, impressive test! For your reference, the linux quirk setting in Widget Control is inactive in the fw versions you have tried.
I have lately had some problems with Windows and 88.2. It's good to know things are improving on Linux and 192.
The firmware I just uploaded uses the same feedback logic as awx_20121213.
Børge
Offline SRC
Guys, just to give you a heads-up: J-River Media Player (on Windows) does sample rate conversion and .wav output.
So now I have a selection of sine wave _and_ Enya at all relevant sample rates
)
I plan to look at the Linux quirk replacement code and determine if there is an 88.2 problem on Windows.
Børge
Guys, just to give you a heads-up: J-River Media Player (on Windows) does sample rate conversion and .wav output.
So now I have a selection of sine wave _and_ Enya at all relevant sample rates
) I plan to look at the Linux quirk replacement code and determine if there is an 88.2 problem on Windows.
Børge
I once tried playing enya backwards.
...sounds like the beatles.
LOL, this got me trying "Paul is dead" English-> Irish on Google translate
Hi,
I have made some changes to the code which replaces the Linux Quirk setting. This is a learning experience to me, so please let me know if you have any comments to what I did. The new code is not yet tested across the board, so if you experience anything being off during testing, let me know. On Win7-32 and Linux 3.0.0-12 Mint 64 (mpd) it works well.
On Windows this experimental firmware requires an updated ASIO driver because it uses 16.16 feedback, not 15.17. Make a backup of C:\Program Files (x86)\Audio Widget\asiouac2.dll and replace it with the one from the download. Make sure your player software is shut down during this operation. There is no need to reboot. On Linux there shouldn't be a need to change any settings. On Mac I haven't yet tested.
The Linux Quirk _used_to_be_ a Widget Control setting which would make the firmware behave differently on Linux and other OSes. For quite a while now the firmware has behaved the same way across all OSes, rendering the quirk useless. In fact, it is not considered in the firmware code.
My goal is interoperability across OSes. I have tried revising the code which replaces the Linux quirk. To test the code, I first disabled certain safeguards and was easily able to replicate the Linux error which Demian detected a while ago. In my tests I go 44-96-48-88. With the safeguards in, I no longer get the Linux error. Both the the revised code and the one in the stable branch remove the error. It might be superstition but I do believe the revised code gives better performance on 88.2 and 96.
For download: awx_20121222b.zip
Here's what I did:
Just like in the stable audio-widget branch, uac2_usb_specific_request.c sets the feedback frequency to 99ksps for 88.2 and 96. That's the safeguard I'm referring to above.
But uac2_device_audio_task.c will do:
rather than:
Like in the stable branch it does this after generating the first feedback package based on 99ksps. I have not yet tried replacing that initial feedback package.
Børge
I have made some changes to the code which replaces the Linux Quirk setting. This is a learning experience to me, so please let me know if you have any comments to what I did. The new code is not yet tested across the board, so if you experience anything being off during testing, let me know. On Win7-32 and Linux 3.0.0-12 Mint 64 (mpd) it works well.
On Windows this experimental firmware requires an updated ASIO driver because it uses 16.16 feedback, not 15.17. Make a backup of C:\Program Files (x86)\Audio Widget\asiouac2.dll and replace it with the one from the download. Make sure your player software is shut down during this operation. There is no need to reboot. On Linux there shouldn't be a need to change any settings. On Mac I haven't yet tested.
The Linux Quirk _used_to_be_ a Widget Control setting which would make the firmware behave differently on Linux and other OSes. For quite a while now the firmware has behaved the same way across all OSes, rendering the quirk useless. In fact, it is not considered in the firmware code.
My goal is interoperability across OSes. I have tried revising the code which replaces the Linux quirk. To test the code, I first disabled certain safeguards and was easily able to replicate the Linux error which Demian detected a while ago. In my tests I go 44-96-48-88. With the safeguards in, I no longer get the Linux error. Both the the revised code and the one in the stable branch remove the error. It might be superstition but I do believe the revised code gives better performance on 88.2 and 96.
For download: awx_20121222b.zip
Here's what I did:
Just like in the stable audio-widget branch, uac2_usb_specific_request.c sets the feedback frequency to 99ksps for 88.2 and 96. That's the safeguard I'm referring to above.
But uac2_device_audio_task.c will do:
Code:
if ( (current_freq.frequency == 88200) && (FB_rate > (98 << 14) ) )
FB_rate = (88 << 14) + (1<<14)/5;
// and similar for 96ksps
Code:
if (((current_freq.frequency == 88200) && (FB_rate > ((88 << 14) + (7 << 14)/10))) ||
((current_freq.frequency == 96000) && (FB_rate > ((96 << 14) + (6 << 14)/10))))
FB_rate -= FB_RATE_DELTA * 512;Like in the stable branch it does this after generating the first feedback package based on 99ksps. I have not yet tried replacing that initial feedback package.
Børge
Last edited:
hello
I tested this version (ab 1.1) on my mac and works fine in all sampling freq. 44.1, 48, 88.2, 96, 176.4, 192. but the noise appears in a different way that previous version. Ramdomly, distorsion appears in a middle of a track, but if you leave playing file, after about 10-15sec, recovers normal function.
I don't checked intensively all sampling frequencies, i don't know if happend at all frequencies, just 192k, and i'd never hear before any distorsion at this frequency.
except for this problem, sound is great.
I hope that this can be help for you.
thanks
juanjo
I found the bug in the ASIO driver. The .dll in the updated .zip works better. The .elf is not updated.
awx_20121222b.zip
Zumbik, I'm must speculating, perhaps the upper 8 bits are discarded because they are 0? You may want to ask at an ALSA forum or mailing list.
Børge
awx_20121222b.zip
Zumbik, I'm must speculating, perhaps the upper 8 bits are discarded because they are 0? You may want to ask at an ALSA forum or mailing list.
Børge
Thanks for doing the test! Obviously, I'd like the noise to go away completely. Once I get hold of a Mac I'll be able to test against it.
In the meantime I have started drafting a new feedback system which isn't quite ready for prime time yet.
Børge
fwiw, I just learned about a neat little linux app, siggen.
at any debian system, you should be able to: 'apt-get install siggen'
it will look like the attached screen-cap (its console based, ncurses to be precise). use the arrows to move around and the values change immediately.
it works over the aw or any sound card on linux/alsa. stop any other audio apps first, though.
...I think this is still better than enya.
at any debian system, you should be able to: 'apt-get install siggen'
it will look like the attached screen-cap (its console based, ncurses to be precise). use the arrows to move around and the values change immediately.
it works over the aw or any sound card on linux/alsa. stop any other audio apps first, though.
...I think this is still better than enya.
Attachments
I tried awx_20121222b.zip in Mac.
192 Noise every few minutes
96 noise every few minutes
88 noise every few minutes
48 noise every a lot of minutes
44.1 noise every a lot of minutes
All times occurs: half a minute before noise internal red LED lights. Increasses flicker speed, noise appears, green LED flicker faster and noise stop.
192 Noise every few minutes
96 noise every few minutes
88 noise every few minutes
48 noise every a lot of minutes
44.1 noise every a lot of minutes
All times occurs: half a minute before noise internal red LED lights. Increasses flicker speed, noise appears, green LED flicker faster and noise stop.
Thanks for testing. With a Mac of my own I'll be able to tweak things some more. The red and green tell me which direction the frequency compensation is taking. Is it always red first and green after?
One thing I've been seeing in highly experimental code is that 44/88/176 are tricier to stabilize than 48/97/192. Are you seeing such a pattern too?
Børge
One thing I've been seeing in highly experimental code is that 44/88/176 are tricier to stabilize than 48/97/192. Are you seeing such a pattern too?
Børge
News about metallic noise ....
First of all I'd like to send my excuses to Borges, after he sent me the tools to debug the board using rs232 I really disappeared ... fact is that I had several problems with my computers, so I was unable to perform real testing.
Now the news.
I have now a macbook pro, and I have performed a lot of testing ....
Using the same old firmware (a version created by me, not modified according the latest developments, but incorporating the new feedback code created by Borges some time ago, probably with some "bug" that he discovered ...
To be short:
- this firmware is causing the "metallic noise" problems under windows xp and windows 7 64 ....
- the same board and firmware perform without problems at all under MacOS (latest version, latest updates): I never experienced ANY form of noise.
The thing I noticed, having introduced in the code a sort of feedback with two leds that are lit one for play and one for rec (in other words, only if different parts of the code are executed ....) is that while under MacOS only the green led (play) is on, under windows also the red led is on (rec) ...
I suppose this is due to the behavior of the Thesycon driver, that actually works always as if both rec and play are working ... actually ignoring the feedback endpoint I suppose.
The fact is that when there is no recording (in other words, under MacOS) everything plays OK, with no trace of noise even in very long sessions ..
This leads me to think that the feedback code is more or less OK, while if we have both rec and play (and the driver actually gets feedback from the rec) there must be something wrong.
Is this of any help?
First of all I'd like to send my excuses to Borges, after he sent me the tools to debug the board using rs232 I really disappeared ... fact is that I had several problems with my computers, so I was unable to perform real testing.
Now the news.
I have now a macbook pro, and I have performed a lot of testing ....
Using the same old firmware (a version created by me, not modified according the latest developments, but incorporating the new feedback code created by Borges some time ago, probably with some "bug" that he discovered ...
To be short:
- this firmware is causing the "metallic noise" problems under windows xp and windows 7 64 ....
- the same board and firmware perform without problems at all under MacOS (latest version, latest updates): I never experienced ANY form of noise.
The thing I noticed, having introduced in the code a sort of feedback with two leds that are lit one for play and one for rec (in other words, only if different parts of the code are executed ....) is that while under MacOS only the green led (play) is on, under windows also the red led is on (rec) ...
I suppose this is due to the behavior of the Thesycon driver, that actually works always as if both rec and play are working ... actually ignoring the feedback endpoint I suppose.
The fact is that when there is no recording (in other words, under MacOS) everything plays OK, with no trace of noise even in very long sessions ..
This leads me to think that the feedback code is more or less OK, while if we have both rec and play (and the driver actually gets feedback from the rec) there must be something wrong.
Is this of any help?