Hi Turbon,
Are you listening with uac1?
If you are, 24/96 does not work. Windows is resampling your music :-(
You can listen with uac2 the same 24/96 music and u should hear the difference. Make sure you set the playback to 24/96 in the driver and the playback software.
There are not that many USB DAC in the market with native 44.1/48/88.2/96/176.4/192 32bit capabilities so most playback software and audio drivers resample automatically.
You need to take extra care to PREVENT resampling
Alex
Are you listening with uac1?
If you are, 24/96 does not work. Windows is resampling your music :-(
You can listen with uac2 the same 24/96 music and u should hear the difference. Make sure you set the playback to 24/96 in the driver and the playback software.
There are not that many USB DAC in the market with native 44.1/48/88.2/96/176.4/192 32bit capabilities so most playback software and audio drivers resample automatically.
You need to take extra care to PREVENT resampling
Alex
Defeating Windows sample rate conversion-Switching drivers and output devices is not enough. You need player software that can pass the audio directly to the hardware. I know JRiver and Foobar can. JPlay may also but there are reports that there are issues with some drivers. There are others as well but its almost a religious war on which to use.
Using Linux for playback is much more manageable.
Using Linux for playback is much more manageable.
Agreed!
I'm starting to believe that Windows-centric audiophiles have an easier time booting into a Linux+player distro than setting up Windows with a foolprof toolchain.
A distro like that could be a thumb drive or a boot DVD. It could set up a config directory on the local file system to make things consistent.
Børge
I'm starting to believe that Windows-centric audiophiles have an easier time booting into a Linux+player distro than setting up Windows with a foolprof toolchain.
A distro like that could be a thumb drive or a boot DVD. It could set up a config directory on the local file system to make things consistent.
Børge
Toolchain issues
Thanks Alex,
I have downloaded the 3.2.3 toolchain for Windows and for Linux. On Windows I'm able to compile, but it gives a faily large .elf file. On that system I already have a lot of Atmel tools installed. On Linux I'm not yet able to compile. I did a tar xvzf of the toolchain files in /install. Other than that it's a fairly fresh Ubuntu 11.10 with no other Atmel tools installed.
My first goal is to compile on both platforms, hopefully replicating Alex's binary output on both of them.
I made a script called make-widget-bsb where I comment out different paths. Other than that and some extra blank lines it is identical to the various other make-widget* files. I have copied in my script at the bottom.
On Linux it says it can't find avr32/io.h. I've done a simple ls -R |less to look for this file in the project files and in the toolchain files. Am I missing something?
b@HP:/media/truecrypt1/kitten/avr32/github/sdr-widget$ ./make-widget-bsb
Compile ../src/AD5301.c
In file included from ../src/I2C.h:14,
from ../src/AD5301.h:11,
from ../src/AD5301.c:10:
../src/SOFTWARE_FRAMEWORK/BOARDS/board.h:55:22: warning: avr32/io.h: No such file or directory
In file included from ../src/I2C.h:26,
from ../src/AD5301.h:11,
from ../src/AD5301.c:10:
../src/SOFTWARE_FRAMEWORK/DRIVERS/TWIM/twim_patched.h:84: error: expected specifier-qualifier-list before 'Bool'
Here's my script:
#!/bin/sh
##
## this makes the widget if the AVR32BIN environment variable
## is pointing to the directory containing avr32-gcc
## Windows setup with Toolchain 3.2.3 at C:\Atmel\AVR Tools\AVR Toolchain
## PATH=${AVR32BIN:="/cygdrive/c/Atmel/AVR Tools/AVR Toolchain/bin"}:$PATH
## Alex's Linux setup:
## PATH=${AVR32BIN:=/home/alex/as4e-ide/plugins/com.atmel.avr.toolchains.linux.x86_64_3.1.0.201012011657/os/linux/x86_64/bin}:$PATH
## Borge's Linux setup:
PATH=${AVR32BIN:=/install/avr32-gnu-toolchain-linux_x86_64/bin}:$PATH
export PATH
cd Release && make all
Borge
Thanks Alex,
I have downloaded the 3.2.3 toolchain for Windows and for Linux. On Windows I'm able to compile, but it gives a faily large .elf file. On that system I already have a lot of Atmel tools installed. On Linux I'm not yet able to compile. I did a tar xvzf of the toolchain files in /install. Other than that it's a fairly fresh Ubuntu 11.10 with no other Atmel tools installed.
My first goal is to compile on both platforms, hopefully replicating Alex's binary output on both of them.
I made a script called make-widget-bsb where I comment out different paths. Other than that and some extra blank lines it is identical to the various other make-widget* files. I have copied in my script at the bottom.
On Linux it says it can't find avr32/io.h. I've done a simple ls -R |less to look for this file in the project files and in the toolchain files. Am I missing something?
b@HP:/media/truecrypt1/kitten/avr32/github/sdr-widget$ ./make-widget-bsb
Compile ../src/AD5301.c
In file included from ../src/I2C.h:14,
from ../src/AD5301.h:11,
from ../src/AD5301.c:10:
../src/SOFTWARE_FRAMEWORK/BOARDS/board.h:55:22: warning: avr32/io.h: No such file or directory
In file included from ../src/I2C.h:26,
from ../src/AD5301.h:11,
from ../src/AD5301.c:10:
../src/SOFTWARE_FRAMEWORK/DRIVERS/TWIM/twim_patched.h:84: error: expected specifier-qualifier-list before 'Bool'
Here's my script:
#!/bin/sh
##
## this makes the widget if the AVR32BIN environment variable
## is pointing to the directory containing avr32-gcc
## Windows setup with Toolchain 3.2.3 at C:\Atmel\AVR Tools\AVR Toolchain
## PATH=${AVR32BIN:="/cygdrive/c/Atmel/AVR Tools/AVR Toolchain/bin"}:$PATH
## Alex's Linux setup:
## PATH=${AVR32BIN:=/home/alex/as4e-ide/plugins/com.atmel.avr.toolchains.linux.x86_64_3.1.0.201012011657/os/linux/x86_64/bin}:$PATH
## Borge's Linux setup:
PATH=${AVR32BIN:=/install/avr32-gnu-toolchain-linux_x86_64/bin}:$PATH
export PATH
cd Release && make all
Borge
Thanks Demian, I add the diode on the board.
I have simulated with another spice model for TL431 placed in my AB.lib download file. Gives similar results.
According to increases capacitor the resonance frequency shifts down. Simulation with 25 uF oscillate at 2 Hz. but in practice I see no problem with 0.1uF and hear better sound than unmodified.
Do you think it's a good idea to put, instead of 0.1uF, a tantalum electrolytic capacitor 100UF 10V of this type?:
http://www.e-merchan.com/pub/uct6u825c.pdf
Perhaps for the analog is good to have a little bit louder lowering the impedance.
In the simulation, when R3 is lower, output impedance decreases. Demian said that may increase noise and worse Q1 into saturation.
Values such as R3 = 220 Oh no saturation appears to Q1 and you get 50 mOh output impedance.
Is it an option for analog AVCC source or there is a mistake that I see?
In the simulation, when R3 is lower, output impedance decreases. Demian said that may increase noise and worse Q1 into saturation.
Values such as R3 = 220 Oh no saturation appears to Q1 and you get 50 mOh output impedance.
Is it an option for analog AVCC source or there is a mistake that I see?
Depending on the application the output impedance may not matter. A crystal oscillator really doesn't need a low Z supply since its power demand doesn't change if its any good and being used properly. The same cannot be said for an opamp passing audio.
The cap that is supposed to affect the stability is probably real in normal applications but doesn't seem that way here. The model is only a model that will show what happens when the part is used as expected. I don't think there are real issues but I'll do some testing when I get a chance.
The cap that is supposed to affect the stability is probably real in normal applications but doesn't seem that way here. The model is only a model that will show what happens when the part is used as expected. I don't think there are real issues but I'll do some testing when I get a chance.
That's what I thought. I'll give it a shot tonight. In the meantime, could you check which versions you're using? I wish to replicate your setup first, then arrive at identical .elf, then try to figure out how to do the same on a Windows installation.
Børge
Børge
why not a 100u or 220u through-hole Elna Silmic II @6.3V? they are small enough to fit and (at least for the analog psu) they'll sound much better than tantalum.
It depends on what you are powering. A well isolated crystal oscillator is as inert as a resistor. It really should not matter what cap you use as long as the value is right.
Okay, I Atmel's AVR32studio version 2.7 for Linux 64,
http://distribute.atmel.no/tools/avr32/beta/as4e-ide-2.7.0.851-linux.gtk.x86_64.zip
and easily ended up with the same subdirectory as you. I moved the stuff to /usr/local/as4e-ide, modified the sript and things compiled right out of the box. No problem, and I didn't have to worry about include file locations or anything.
The resulting .elf file is 169224 bytes long, 24 bytes larger than the usual size of Alex's binaries. Alex, I assume you're using the 64-bit variety.
When I use AVR32studio 2.7 for Windows with the same toolchain version setup I get a file which is 412991 bytes long. Only the path is changed. Makefile and source are the same. I do make clean for each run.
So clearly there are differences between compiling on a Linux and a Cygwin platform. I'll ask at avrfreaks if they know why there is a difference. Perhaps it boils down to a simple configuration issue. Where might one look for a global toolchain config file?
In the meantime I'd appreciate any input on this. Several you are more well versed with compiler setups than myself.
Børge
http://distribute.atmel.no/tools/avr32/beta/as4e-ide-2.7.0.851-linux.gtk.x86_64.zip
and easily ended up with the same subdirectory as you. I moved the stuff to /usr/local/as4e-ide, modified the sript and things compiled right out of the box. No problem, and I didn't have to worry about include file locations or anything.
The resulting .elf file is 169224 bytes long, 24 bytes larger than the usual size of Alex's binaries. Alex, I assume you're using the 64-bit variety.
When I use AVR32studio 2.7 for Windows with the same toolchain version setup I get a file which is 412991 bytes long. Only the path is changed. Makefile and source are the same. I do make clean for each run.
So clearly there are differences between compiling on a Linux and a Cygwin platform. I'll ask at avrfreaks if they know why there is a difference. Perhaps it boils down to a simple configuration issue. Where might one look for a global toolchain config file?
In the meantime I'd appreciate any input on this. Several you are more well versed with compiler setups than myself.
Børge
Supported sample rates?
I just had occasion to query the USB interface (Linux) and the AB1.1 seems to have support for some rates that don't seem right:
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 = 192031 Hz (0x18.0100)
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
132,300 and 144,000 seem odd and may not be right.
I still have the problem of the device selecting the wrong clock rate during sample rate switching from low to high sometimes.
It also seems the host's clock is a little off (16Hz at 192K) but the process is proceeding flawlessly.
I just had occasion to query the USB interface (Linux) and the AB1.1 seems to have support for some rates that don't seem right:
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 = 192031 Hz (0x18.0100)
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
132,300 and 144,000 seem odd and may not be right.
I still have the problem of the device selecting the wrong clock rate during sample rate switching from low to high sometimes.
It also seems the host's clock is a little off (16Hz at 192K) but the process is proceeding flawlessly.
As I posted before on the issue of clock switching under certain conditions (eg using mpd to play mixed sample rate album) the player software finds it convenient to just change the audio stream to a different sample rate without sending a proper uac2 command to switch sample rate.
The solution that I have been working on is to have a watchdog process monitoring the incoming USB stream and compute the likely sample rate (instead if the current firmware that waits for the uac2 command). It then switches the widget sample rate accordingly.
I will have to play with this to see whether this will have any adverse impact on the SQ.
If u try programs such as PurePlayer on Windows you will find it can play mixed sample rate playlist with no issues.
I will post when I have a new firmware with the unannounced sample rate change watchdog working.
Alex
The solution that I have been working on is to have a watchdog process monitoring the incoming USB stream and compute the likely sample rate (instead if the current firmware that waits for the uac2 command). It then switches the widget sample rate accordingly.
I will have to play with this to see whether this will have any adverse impact on the SQ.
If u try programs such as PurePlayer on Windows you will find it can play mixed sample rate playlist with no issues.
I will post when I have a new firmware with the unannounced sample rate change watchdog working.
Alex
I have uploaded a new firmware with fix for unannounced sample rate change in certain playback software issue. Only catches changing from a low samplinng rate to 96khz or 192khz.
audio-widget-nik-2011-01-20.elf - sdr-widget - Unified firmware for audio-widget. Fixed unannounced sample rate change in certain playback software issue. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hos
Please test and see whether it solves the mixed sampling rate album issue, and also whether there is any adverse impact on the SQ.
Alex
audio-widget-nik-2011-01-20.elf - sdr-widget - Unified firmware for audio-widget. Fixed unannounced sample rate change in certain playback software issue. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hos
Please test and see whether it solves the mixed sampling rate album issue, and also whether there is any adverse impact on the SQ.
Alex