I have not built the shunt version, no time. Its so simple it would not take much to breadboard and test.
I'll publish the circuit for my low noise preamp for testing these low noise supplies very soon now that its working. I got the equivalent input noise to below 5 Ohms it seems. Now to make sure that's not me blowing the measurement. . .
> you know, a digital capture field recorder might be a really nice project...
Yes, would it be difficult to create a working interface for linux using
- http://www.qnktc.com USB-I2S Module
Dual stereo ADC for example WOLFSON - WM8788GEDT/R - low cost decent performance.
and Dual stereo DAC - do not really have a preference for chip with line out.
Any idea IF 4 channel input would have a chance to work in linux within for example 3 months from now?
Yes, would it be difficult to create a working interface for linux using
- http://www.qnktc.com USB-I2S Module
Dual stereo ADC for example WOLFSON - WM8788GEDT/R - low cost decent performance.
and Dual stereo DAC - do not really have a preference for chip with line out.
Any idea IF 4 channel input would have a chance to work in linux within for example 3 months from now?
Starn02 do you know if is possible to run Atmel Studio 6 in linux using Mono by Miguel Icaza?
tks
Joao
Hi i have a problem with my QNKTC AB 1.1 with Sabre ES9023.
I have latest Audio-Widget and ASIO drivers installed.
I also upgrade my dac to latest FW.
I use foobar2000 and Windows 8 64bit.
The problem is when I listen to music on UAC2, it plays first track fine, but when i click next-track (or drag the time indicator) it suddenly stop playing, and track time counting is stopped.
I must restart foobar or unplug and plug dac again (or just stop (not pause) song and play it again) and then it works - but after i click next-track or rewind it freezez again.
UAC1 works fine.
Can anybody help me?
I have latest Audio-Widget and ASIO drivers installed.
I also upgrade my dac to latest FW.
I use foobar2000 and Windows 8 64bit.
The problem is when I listen to music on UAC2, it plays first track fine, but when i click next-track (or drag the time indicator) it suddenly stop playing, and track time counting is stopped.
I must restart foobar or unplug and plug dac again (or just stop (not pause) song and play it again) and then it works - but after i click next-track or rewind it freezez again.
UAC1 works fine.
Can anybody help me?
Last edited:
Metallic noise again ...
I incorporated the changes in code by Borges regarding metallic noises in the code that I use ...
Initially it seemed better, but after longer testing I noticed that metallic noises are sometimes still present (at least at 96k and 192k).
What's the situation in other installations? Is anybody having "rithmic metallic noise" occasionally during playback?
I incorporated the changes in code by Borges regarding metallic noises in the code that I use ...
Initially it seemed better, but after longer testing I noticed that metallic noises are sometimes still present (at least at 96k and 192k).
What's the situation in other installations? Is anybody having "rithmic metallic noise" occasionally during playback?
Last edited:
Hi,
I'm assuming this is happening on Win7+UAC2+ASIO driver. Correct? Are you getting the noise at random times in the music, or when you pull the time bar in foobar2000?
The feedback generating algorithm in the firmware is tricky business. Things did improve noticeably with the new firmware. Still, there may be potential for improving the algorithm even further, so please keep us posted on what it takes to bring out the noise now. And feel free to play with the firmware code, too!
People who had noise issues before came back and reported that 10 hours of listening didn't produce a single issue.
Børge
Sadly this still seems to be a big problem. Not only on windoze.
(...curiously, the only system with wich I've never had any major problem is Linux).
Recently I've had the chance to try my AB1.1 (with latest firmware) on a MacOS/X system. A relatively old one, unfortunately: UAC2 was not supported, thus I could not try it. I switched to UAC1 and it did work... well, sort of.
The first track plays ok. The bad surprise arrived when the track ended and the next one started to play.
As it turns out, at every track change the sync get lost (I guess... or some other problem happens) and the new track become badly distorted with the well-known "metallic" kind of sound.
(somethimes the same happen also when moving/jumping within a track).
Pushing "Stop" and then "Play" again on the player seems restore the normal sound... until the next track begins to play.
(...curiously, the only system with wich I've never had any major problem is Linux).
Recently I've had the chance to try my AB1.1 (with latest firmware) on a MacOS/X system. A relatively old one, unfortunately: UAC2 was not supported, thus I could not try it. I switched to UAC1 and it did work... well, sort of.
The first track plays ok. The bad surprise arrived when the track ended and the next one started to play.
As it turns out, at every track change the sync get lost (I guess... or some other problem happens) and the new track become badly distorted with the well-known "metallic" kind of sound.
(somethimes the same happen also when moving/jumping within a track).
Pushing "Stop" and then "Play" again on the player seems restore the normal sound... until the next track begins to play.
This is interesting. There was a buffer init bug in UAC2 which I also found in the UAC1 code. Plus, the UAC1 feedback logic has been changed (not by me).
Let's focus on UAC1+Mac first. I have compiled two firmware versions, one where I have reverted only the buffer init bug fix, and one where I have reverted UAC1 feedback code. Both play on my Win7-32 system. Could you try both on your setup and let me know how this works on UAC1 with the Mac? I don't have a Mac to test here.
The fw is at:
awx_20121116_Mac_experimental.zip - sdr-widget - Experimental firmware for debugging UAC1 on Mac - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
Børge
Let's focus on UAC1+Mac first. I have compiled two firmware versions, one where I have reverted only the buffer init bug fix, and one where I have reverted UAC1 feedback code. Both play on my Win7-32 system. Could you try both on your setup and let me know how this works on UAC1 with the Mac? I don't have a Mac to test here.
The fw is at:
awx_20121116_Mac_experimental.zip - sdr-widget - Experimental firmware for debugging UAC1 on Mac - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
Børge
was that fixed only in UAC2?
who did that? is the logic supposed to be the same for both UAC1 and UAC2?
(if it is, I guess it would be better to try to keep the code the same to avoid inconsistencies...).
in UAC2, UAC1 or both?
if/when I can get access to a MacOS/X system again I'll try.
good to know. Could oyu please try in UAC1 too? Which player are you using on the Mac?
Last edited:
Hi Borges, sorry for the late reply but I did not check diyaudio for a while.
As regards the "metallic noise" problems I can give you more details:
- they happen in windows 7 and XP with UAC2, and at different sampling frequencies (surely at 96, 48 and 192)
- it's something that happens after some time listening to music ... maybe 10, 20 minutes, or even an hour ...
- it starts like a repetitive metallic noise, a high frequency distortion or clipping ... initially low, a sort of beat, then becomes louder, finally all the music is messed ... then it decreases, and if you are patient enough it finally fades away.
- when you have such noise pausing and restarting foobar has no effect, but if you switch sampling frequency on the fly (I use a resampler in foobar) it goes completely away (I suppose because when you switch frequency the main variables are reinitialized)
My opinion is that after some time something in the pointers or indexes that are used to play samples become corrupted, maybe because the adjustment of number of samples becomes wrong. I'm unable to "debug" such situations using the Atmel Studio IDE, it's impossible to examine the internal variables while the program is running.
As I have now incorporated also a CDC interface in the USB descriptors I will probably try to write debug messages on it in order to understand. Probably by writing the indexes value, or the value of main variables, I can figure out what happens during the "metallic noise" phase.
As regards the "metallic noise" problems I can give you more details:
- they happen in windows 7 and XP with UAC2, and at different sampling frequencies (surely at 96, 48 and 192)
- it's something that happens after some time listening to music ... maybe 10, 20 minutes, or even an hour ...
- it starts like a repetitive metallic noise, a high frequency distortion or clipping ... initially low, a sort of beat, then becomes louder, finally all the music is messed ... then it decreases, and if you are patient enough it finally fades away.
- when you have such noise pausing and restarting foobar has no effect, but if you switch sampling frequency on the fly (I use a resampler in foobar) it goes completely away (I suppose because when you switch frequency the main variables are reinitialized)
My opinion is that after some time something in the pointers or indexes that are used to play samples become corrupted, maybe because the adjustment of number of samples becomes wrong. I'm unable to "debug" such situations using the Atmel Studio IDE, it's impossible to examine the internal variables while the program is running.
As I have now incorporated also a CDC interface in the USB descriptors I will probably try to write debug messages on it in order to understand. Probably by writing the indexes value, or the value of main variables, I can figure out what happens during the "metallic noise" phase.
More details:
- never had problems when pulling the bar in foobar
- I use only UAC2, so I don't know if the same problem can be found in the test firmware that you have recently developed.
- the problem is the same with 2 different versions of the windows drivers that I have hacked (although they behave completely different for other aspects), so I don't know if it's a windows driver problem or not.
What I know is that such drivers are designed to use the data rate of the samples going back to the pc to reconstruct the "adaptive" number of samples to send to the playback end point. As far as I see they work either using the information on the feedback endpoint or the number of samples on the "recording endpoint".
In my case, as I have now the recording part working, I can say that the problem happens both when I'm also recording or when I'm listening only.
But I have noticed in the code that the playback part assumes that the playback slot is always completely full of samples (number of samples = size of endpoint buffer / 8), so I have a doubt ... is this always correct? When the driver "adaptively" sends less or more data ... is it possible that sometimes we use some sample at zero that was not really sent, so introducing a gap that could explain the distortion that we hear?
- never had problems when pulling the bar in foobar
- I use only UAC2, so I don't know if the same problem can be found in the test firmware that you have recently developed.
- the problem is the same with 2 different versions of the windows drivers that I have hacked (although they behave completely different for other aspects), so I don't know if it's a windows driver problem or not.
What I know is that such drivers are designed to use the data rate of the samples going back to the pc to reconstruct the "adaptive" number of samples to send to the playback end point. As far as I see they work either using the information on the feedback endpoint or the number of samples on the "recording endpoint".
In my case, as I have now the recording part working, I can say that the problem happens both when I'm also recording or when I'm listening only.
But I have noticed in the code that the playback part assumes that the playback slot is always completely full of samples (number of samples = size of endpoint buffer / 8), so I have a doubt ... is this always correct? When the driver "adaptively" sends less or more data ... is it possible that sometimes we use some sample at zero that was not really sent, so introducing a gap that could explain the distortion that we hear?