Open-source USB interface: Audio Widget

The "momentary" frequency says what it means :)

Based in the rate feedback, the host (PC) changes its freq momentarily to keep feeding the samples to the widget accordingly to the widget's clock.

So the PC will be sending samples NOT exactly at 44100 but near it and will vary from moment to moment :)

Alex
 
The "momentary" frequency says what it means :)

Based in the rate feedback, the host (PC) changes its freq momentarily to keep feeding the samples to the widget accordingly to the widget's clock.

So the PC will be sending samples NOT exactly at 44100 but near it and will vary from moment to moment :)

Alex

fine, something like that was what I thought it should be...:)
 
I do not know, in Linux MPD server, how to configure a resamplig and a memory playback from a WAV file.
192000 resampling is even better. Playing the file from memory may be better.
resampling should be easy, check the config file. I guess you just need to set:

Code:
audio_output_format            "192000:24:2"
samplerate_converter           "Best Sinc Interpolator"

for what regards playing from memory, I'm afraid that can't be done without modifying the MPD source code.

On the other end, the easiest way to do some test to verify whether doing so would really be useful, is to play directly from the command line, using a simple script. Some time ago I had prepared a few ones exactly for this purpose. Check here:

www.audiofaidate.org - Con Linux sulla via del cMP²

the relevant script is this one:

Code:
#!/bin/bash

# copy specified files into the RAM-disk
#
declare -a playlist
i=1
for file in "$@"; do
   cp -v "$file"  /dev/shm/
   playlist[$i]="/dev/shm/`basename "$file"`"
   let i++
done

# play files from RAM-disk (with online upsampling)
#
schedtool -a 0,1 -R -p 10 -e \
sox -S -V3 --single-threaded --combine sequence "${playlist[@]}" \
 -t alsa -b 32 hw:0,0 \
 gain -3 \
 rate -v -I 192000

# clean-up the RAM-disk
#
rm -vf "${playlist[@]}"

save it as "mplay.sh" (or whatever you like), make it executable (chmod +x mplay.sh), and use it as follows:

./mplay.sh /path/to/some/audio_files/*.ext

edit: of course, the script supports all of the file formats supported by "sox" (thus usually including flac, wv, wav, etc). The use of "schedtool" to apply real time scheduling to the play process is optional (it can safely be omitted). You may want to play with schedtool options to see whether that makes any difference. And of course you may want to play with SOX options too.
 
Last edited:
resampling should be easy, check the config file. I guess you just need to set:

Code:
audio_output_format            "192000:24:2"
samplerate_converter           "Best Sinc Interpolator"

Thanks Unixman. I'll try.

I do not know whether Linux resampling will improve the sound, depends on the quality of the resampler. With most card and Windows programs is often worse with resampler.

The resampler Pure Music is excellent, but the Mac's own resampler is almost as good with changes in OSX and iTunes at the beginning of last year.

Several DAC with Hiface on MAC I have measured better background noise: 1.5 dB from 44 to 48 and another 1.5 dB to 92, does not improve to 192.

With Audio Widget on MAC I think have a progressive improvement up to 192 . In WindowsXP I could only test 44 to 48 with Foobar2000 and SoX and also seems to improve slightly.
 
Resampling in MPD is done using libsrc (that is the famous "Secret Rabbit Code", one of the best available algorithms).

On the other end, using the suggested script you'll be using SOX, thus you can use any of the several algorithms (and settings) supported by that powerful software. With the suggested options (rate -v -I) you'll be using the best sox algorithm (which is one of the absolute best ever) using "Intermediate phase" settings (which is what I subjectively like most for listening). You can change options to use whatever setting you like. From the command line sox offers way more options than using the limited Foobar SOX plugin.
 
With MPD an option to try could be "live stream" mode, that is receiving the data stream through the network instead of having MPD read it from a disk file. That way the stream may also be upsampled on the stream source (if so desired), off-loading the local CPU from that heavy task. I have never tried that though, not even well checked the required setup details.
 
With MPD an option to try could be "live stream" mode, that is receiving the data stream through the network instead of having MPD read it from a disk file. That way the stream may also be upsampled on the stream source (if so desired), off-loading the local CPU from that heavy task. I have never tried that though, not even well checked the required setup details.

What I tried is having the music-dir on an external server (via nfs) and copying the music-dir on a ramdisk. Both options sound better, but need some scripting or a 2nd computer.

Rüdiger
 
What I tried is having the music-dir on an external server (via nfs) and copying the music-dir on a ramdisk. Both options sound better, but need some scripting or a 2nd computer.
interesting. Thus it looks like direct HDD access is a possible source of problems. Either the noise produced by the HDD and/or the IRQ processing are possible suspect.

Have you tried reading from an external (USB/FW/eSATA) HDD powered from its own, external PSU?
 
No, I didn't. I plan to test SSD's in the future, though.

Since the client/server model is the one i will implement on a permanent base, I will eventually test network vs. ram-playback, but I believe the differences will be to small to notice (at least to me).

Rüdiger
 
With MPD an option to try could be "live stream" mode, that is receiving the data stream through the network instead of having MPD read it from a disk file. That way the stream may also be upsampled on the stream source (if so desired), off-loading the local CPU from that heavy task. I have never tried that though, not even well checked the required setup details.
Can somebody point me in the direction of a tutorial/info on how to use mpd to stream raw pcm from a server to a client computer (both running linux). Both computers belong to the same ethernet network so bandwith is not a problem.

TIA
giulio
 
USB i2S for other dacs

Hi,

I post here to show my interest in standalone usb I2S module as asked before by other people.
Since I want to interface it with the buffalo dac, I can't provide my own clocks needed by the usb i2s module. I also have an opus dac, which is a woflson 8741 in slave mode.
So for both dacs, I need an usb i2s module with just the two clocks (and divider).
I can see that it could be interesting even for the buffalo in async mode since it will allow to use a i2s isolator (with the introduced jitter properly cleaned by the 9018 dac).
The same design module will also suits perfectly the opus dac.
So if this board will be available, I will prefer to buy two modules like this than a module and AB1.1.
One note is that I am really interested in the your usb module since it could be possible to configure the dac (wolfson and 9018) with the I2C bus ! I will even use the SPI bus to pilot a small screen (or a simple char LCD) for the ultimate solution.
I plan to use an arduino board for screen and I2C piloting, and take a look at the complexity to integrate I2C piloting in the firmware if it is not already done by others. I think a lot of people will be interested of this implementation for the 8741 and 9018, which are really great dacs.

Thanks for your work !
 
I agree with Demian. The ES9023 is an SOIC package with 50mil pin spacing. I am considering a revised module which will be available stand-alone. If room premits this will also have the option of fitting oscillators on it.

But this thing lies a bit into the future. So if you want something to play with now and which will interface your equipment, the AB-1.1 is probably the easiest way to go.

To help out with the next stage feel free to suggest IO pinning and voltage levels for the I2S. Also, should an I2S header have MCLK in or out?

Børge
 
I see your point about the AB1.1 and I had decided to go this way if thare is no other (which is what I presented). It is just to state that for my needs, fit an AB 1.1 in my dac just to take the i2s is not optimal.
Maybe I am not the only interested, which will give value to a specific usb i2s module with just the clocks and divider with I2S output (witg MCLK out I thin), just as the M2tech OEM board. With two separate LDO regulators (one for the processor and one for the clocks). IO should have moreover I2C, SPI and few free IO.
That is my current dream !
Anyway, if no one is interested and this solution too far I will be happy with AB1.1 (at least if I can save on the box).

Louis.
 
An i2c bus and a char LCD connector are already available on the USB-I2S module. The LCD displays a bar graph of the audio out like a VU meter. The firmware can be modified for improved display (on TODO list) of sampling rate etc.

Also in the TODO list is I2C control for ES9018 and WM DAC's. That is for the future :). If you are interested the firmware is open source and you can join the developers :)

Alex
 
To the attention of Børge

Citation from
Voyage Linux | { x86 Embedded Linux = Green computing }

To broaden the use of Voyage Linux, Voyage Linux community is now looking for generous donation and sponsorship of x86 embedded boards and USB Audio Class 2 DAC/audio converters. If you are hardware vendor or ISP and your customers are asking for supporting Voyage Linux in your hardware, please send your hardware to us for certification and testing. Contact us for more details.

Is AW included?

Thanks

Juan