just as a spoiler alert, sort of (lol), I have a system where the volume control IS done entirely outside of the dac or spdif transport (whether its pci based spdif or usb based). the screen cap shows the alsamixer having a Master element there. you can drag that up and down all you like and it never alters the bit-perfect spdif output, at least with usb audio (both the AW and my older usb1 based 44/48k dongles).
the real-world link is that I have a process that scans the mixer device for value changes on Master and then sends rs232 control messages to keep the *real* volume control updated. its sort of an intercept style, where the system vol control looks like any other on linux, but moving it causes a real world item to move instead of a software value shift of the bit stream.
the device at the other end is currently my own device, the LCDuino system that controls relay attens or PGA chips. it has a serial control slave port of its own and that makes it remote controllable over rs232/ttl. you link up the 'amixer' part (that detects system fader value changes) with the external serial controlled box and you then have all the right parts done at the right places (imho).
when I run MPD, for example, I can have MPD think that there is a hardware vol control called Master. the only vol control you then see on any MPD interface becomes this one. this one now links to the rs232-controlled real world device and that does your real attenuation. or if you use local apps (like audacious) their volume slider also asumes 'Master' and so it can control your stereo, too.
that's my approach (and my test setup is all working!). its not quite the approach of the audio widget, though; as the control channel requires the usb path to be there and this device to be there. with my scheme, its independant of what usb sound card you have.
the real-world link is that I have a process that scans the mixer device for value changes on Master and then sends rs232 control messages to keep the *real* volume control updated. its sort of an intercept style, where the system vol control looks like any other on linux, but moving it causes a real world item to move instead of a software value shift of the bit stream.
the device at the other end is currently my own device, the LCDuino system that controls relay attens or PGA chips. it has a serial control slave port of its own and that makes it remote controllable over rs232/ttl. you link up the 'amixer' part (that detects system fader value changes) with the external serial controlled box and you then have all the right parts done at the right places (imho).
when I run MPD, for example, I can have MPD think that there is a hardware vol control called Master. the only vol control you then see on any MPD interface becomes this one. this one now links to the rs232-controlled real world device and that does your real attenuation. or if you use local apps (like audacious) their volume slider also asumes 'Master' and so it can control your stereo, too.
that's my approach (and my test setup is all working!). its not quite the approach of the audio widget, though; as the control channel requires the usb path to be there and this device to be there. with my scheme, its independant of what usb sound card you have.
Attachments
Last edited:
can you give me more example... i am facing same issue ..i have puppy mpd and the sound is off the chart i am unable to control the volume any mean ...
can you explain how u did it...
I plan to list all the steps to get it going, but I'm not ready yet.
it involves a bit of alsa 'magic' (to me, I'm not well versed in alsa architecture or api's yet), plus the ability to control some real-world device over a serial port or possible tcp network port.
ie, I like using the linux system to pass vol-control requests and UI feedback but I don't want the software to do attenuation via software; I prefer it twiddle a real world knob (literally or figuratively) when the user asks for a volume raise or lower.
what I did, just to get something going, was to get an alsa build environment and copy/adapt the 'amixer.c' program. it seems as good as any for a lean example of how to read and write the system volume mixer settings.
once I hacked that, I could call it as a shell program and be able to read/write the system Master mixer element. something like:
% ./vm_mixer
113
% ./vm_mixer 205
205
one call simply gets the current 0..255 value and the 2nd way sets it. something that simple is what I have going right now.
the other end is a similar deal; a program that you can call to GET and SET the value to the real world vol control.
the last bit is to run them both in an alternate polling loop and when the real world control changes, up date the linux view. when the linux slider changes, move the real world control. that's the last part that I'm now working on. when its ready, I'll post a link for people to try out. you'll have to glue on your own real-world back-end but the plumbing will at least be there for you.
it involves a bit of alsa 'magic' (to me, I'm not well versed in alsa architecture or api's yet), plus the ability to control some real-world device over a serial port or possible tcp network port.
ie, I like using the linux system to pass vol-control requests and UI feedback but I don't want the software to do attenuation via software; I prefer it twiddle a real world knob (literally or figuratively) when the user asks for a volume raise or lower.
what I did, just to get something going, was to get an alsa build environment and copy/adapt the 'amixer.c' program. it seems as good as any for a lean example of how to read and write the system volume mixer settings.
once I hacked that, I could call it as a shell program and be able to read/write the system Master mixer element. something like:
% ./vm_mixer
113
% ./vm_mixer 205
205
one call simply gets the current 0..255 value and the 2nd way sets it. something that simple is what I have going right now.
the other end is a similar deal; a program that you can call to GET and SET the value to the real world vol control.
the last bit is to run them both in an alternate polling loop and when the real world control changes, up date the linux view. when the linux slider changes, move the real world control. that's the last part that I'm now working on. when its ready, I'll post a link for people to try out. you'll have to glue on your own real-world back-end but the plumbing will at least be there for you.
if anyone wants a weekend project (arduino based), here's an easy one.
its an spdif meter that converts word-clock frequency (from your i2s line or dac or spdif receiver chip) into a discrete led that you can display.
here's the arduino code: Index of /spdif_meter_simple
grab the .zip file there and all you care about is the .pde file (usual for arduino; that's the only C file in this project). you could load it directly into the arduino GUI and press 'play' (build). it should build on the last NON-1.0 arduino environment (ie, 0022). the makefile should also work if you edit the ARDUINO_ROOT to point to where your 'hardware' and 'libraries' and 'reference' folders are, if you installed the arduino linux pkg.
pics of what my proto looks like:
http://farm8.staticflickr.com/7178/6931855681_0ff25bd48c_b.jpg
http://farm8.staticflickr.com/7187/6788052170_b3b6e5b8c9_b.jpg
and mounted in my diy dac; the cluster of leds to the far left is this board:
http://farm8.staticflickr.com/7064/6790083302_565846af54_b.jpg
you could use any 328 series arduino (or even 168). the leds go to pins as follows:
#define LED_44 A3
#define LED_48 A2
#define LED_88 A1
#define LED_96 12
#define LED_176 10
#define LED_192 9
and those are the SR's that this device supports. for the odd guy of 32k, the bottom 2 leds should light up (44+48). all others have their own led to show samplerate.
maybe there will be a pcb made for this (anyone want to volunteer?) but you can see that perfboarding this is not hard at all. a 16mhz resonator is the only 'odd' part you'd need.
pin5 gets the word-clock input and I used a 74hc14 (iirc) as a shaper between the spdif receiver chip's WC out and the pin5 of the arduino.
if you ever need to spy on your spdif and be sure what rate your are locked in as, this could be a useful tool for you. or just build it into your spdif transmitter system (like the audio widget) or even inside your dac (like I did).
hope someone finds it useful
its an spdif meter that converts word-clock frequency (from your i2s line or dac or spdif receiver chip) into a discrete led that you can display.
here's the arduino code: Index of /spdif_meter_simple
grab the .zip file there and all you care about is the .pde file (usual for arduino; that's the only C file in this project). you could load it directly into the arduino GUI and press 'play' (build). it should build on the last NON-1.0 arduino environment (ie, 0022). the makefile should also work if you edit the ARDUINO_ROOT to point to where your 'hardware' and 'libraries' and 'reference' folders are, if you installed the arduino linux pkg.
pics of what my proto looks like:
http://farm8.staticflickr.com/7178/6931855681_0ff25bd48c_b.jpg
http://farm8.staticflickr.com/7187/6788052170_b3b6e5b8c9_b.jpg
and mounted in my diy dac; the cluster of leds to the far left is this board:
http://farm8.staticflickr.com/7064/6790083302_565846af54_b.jpg
you could use any 328 series arduino (or even 168). the leds go to pins as follows:
#define LED_44 A3
#define LED_48 A2
#define LED_88 A1
#define LED_96 12
#define LED_176 10
#define LED_192 9
and those are the SR's that this device supports. for the odd guy of 32k, the bottom 2 leds should light up (44+48). all others have their own led to show samplerate.
maybe there will be a pcb made for this (anyone want to volunteer?) but you can see that perfboarding this is not hard at all. a 16mhz resonator is the only 'odd' part you'd need.
pin5 gets the word-clock input and I used a 74hc14 (iirc) as a shaper between the spdif receiver chip's WC out and the pin5 of the arduino.
if you ever need to spy on your spdif and be sure what rate your are locked in as, this could be a useful tool for you. or just build it into your spdif transmitter system (like the audio widget) or even inside your dac (like I did).
hope someone finds it useful
yes you can reproduce it quite easily on linux... with almost any player that has low latency settings
one interesting thing is that when i'm playing music UAC1 and start Chrome/Chromium... just before it loads the whole page the playback speeds up not sure why but only Chrome/Chromium does that
just to let you know
one interesting thing is that when i'm playing music UAC1 and start Chrome/Chromium... just before it loads the whole page the playback speeds up
not sure why but only Chrome/Chromium does thatjust to let you know
Last edited:
One more newbie question if I may Børge, do you know the total current draw of the Audio Widget (AB1.1)? After success trying out a simple external psu for it I'm now getting the parts together to built a 5v Salas Shunt Reg.
This really is the best digital sound I've heard in my system to date, even beating an Audiolab MDAC I owned for a few months. It's also beaten my modded Gigaworks CS4398 dac which was my previous favourite. Love it's unforced clarity, ability to hear deep into a recording, and the bass punch is absolutely phenominal! Truly analogue sounding at times! Great DAC
John.
John, I don't have the number. Look at the AB-1.1 analog board schematic at Q N K T C USB-I2S Module and Analog Board 1.1
All current in the system goes through R26 and you can easily swap it for an amp meter. After R26 are various LDOs, so replacing it with a sense resistor and a differential 'scope is also something you can try.
The AB-1.2 works the same way.
Børge
All current in the system goes through R26 and you can easily swap it for an amp meter. After R26 are various LDOs, so replacing it with a sense resistor and a differential 'scope is also something you can try.
The AB-1.2 works the same way.
Børge
Thanks for that Børge - I'll measure across R26 as you suggest, if my probes can fit onto those tiny pads
R26 has already been removed anyway as I'm using an external PSU.Also remembered that the USB1.0/2.0 spec is only up to 500mA, so it wouldn't be more than that at any rate.
- John
Right just measured the current over the pads where R26 used to be - total current draw is only 24.4mA.
Word of caution to anyone else that needs to measure this - as soon as my probes were touching the R26 pads, my Mac mini that the Audio Widget is connected too suddenly shut down, & the fan suddenly started whirring at high speed. Thankfully no damage appears to have been done - whew! (touch wood!). Next time I'd disconnect the USB cable first...
- John
Word of caution to anyone else that needs to measure this - as soon as my probes were touching the R26 pads, my Mac mini that the Audio Widget is connected too suddenly shut down, & the fan suddenly started whirring at high speed. Thankfully no damage appears to have been done - whew! (touch wood!). Next time I'd disconnect the USB cable first...
- John