• The Vendor's Bazaar forum is for commercial offers and transactions. Only unmoderated members can post here.

    diyAudio provides this forum for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members. Use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

USB to I2S 384Khz - DSD Converter

Jump to Latest
#121
bcmbob said:
Pleas excuse this little sidebar, but I would like a bit more base information. Generally my question is "What will this device do for the audio I hear?"

There is not a lot of program material I have access to that is recorded beyond 192K, so the higher sampling rates don't initially seem all that beneficial.

Secondly, my Mini2496 DAC is fitted with selectable S/PDIF brought in by a BNC chain direct from pins on the computer motherboard - or the standard on-board optical out. My preference so far is the BNC but am fully open to other input techniques. I even started a thread in hopes of investigating the use and advantages of I2s.

I'll simply state my limited understanding and request clarification/correction where it applies.

1. It appears to me that the main purpose of this and similar devices is to correct and/or compensate for flaws inherent in using USB as an audio signal transport.
Click to expand...
I was going to disagree with this statement, but on re-consideration, I think clarification may help. These kind of devices (at least UAC 2.0 compatible ones), allow a user to take advantage of the greatly improved(vs USB1.0) Audio transfer capabilities of a USB 2.0 Spec interface. Asynchronous transfer of the data (meaning the "transport" (ie the USB-I2S converter) is the source of the clock) if done correctly can reduce jitter considerably. I looked again and I can't see that the Amanero device is Asynchronous, need to confirm that. Jitter performance is where Async USB has an advantage over SPDIF(according to some people anyway). There is a lot of debate over which transport mechanism is superior. USB does have an advantage in that it is Ubiquitous, not all computers have SPDIF outputs.

2. Using a direct S/PDIF feed can avoid or minimize such problems.
Click to expand...
What problems exactly?

3. By design, each specific DAC chip already internally resolves to I2s, and this device is more or less an off-loading or substitution of that process.
Click to expand...
Well, this isn't strictly true. The ESS9018 chip does accept SPDIF directly and is capable of reclocking the data to eliminate jitter in the data stream, but the WM8741 requires conversion to I2S from SPDIF.. I believe most DAC chips require some sort of SPDIF to I2S converter chip in front of them. The ASRC chips used in many DAC's perform the same service of reclocking (and usually upsampling) the SPDIF data stream for delivery to the DAC chip itself via I2S.
4. The software/driver hook is primarily a tool for DSP adjustments (e.g. frequency manipulation) and not necessarily intended as a method of purifying the base signal.
Click to expand...
I think that is a bit too general. Drivers are required in the Window's world for USB 2.0 devices to be able to communicate with the CPU, but they have nothint to do with "purification". If the transport is "bit perfect", then there should not be any "purification".
The ASIO driver many of these devices use actually bypasses many of the Windows Audio manipulation programs, and in this case prevents "pollution" of the audio signal even before it reaches the DAC.
Apple OSX and recent versions of Linux support UAC 2.0 specification devices directly, without any additional drivers required..
So, admittedly with the gaps in my understanding. I would appreciate someone more accurately detailing where this device optimally fits in the audio chain and the comparative advantages of its use. To date, I'm still experiencing a bit of a fog here.

Thanks
Click to expand...
 
#124
MrSlim/qusp, that helps a lot. I am using the WASAPI Event Style option in JRiver which reportedly is a direct link to the dac and it sounds very clean and balanced.

Would welcome additional comments but I'm in, and I hopefully will learn much more in the process.
 
#125
bcmbob said:
MrSlim/qusp, that helps a lot. I am using the WASAPI Event Style option in JRiver which reportedly is a direct link to the dac and it sounds very clean and balanced.

Would welcome additional comments but I'm in, and I hopefully will learn much more in the process.
Click to expand...

Well, this would be a great way for you to try something different, without spending a lot of money(although you would need a DAC with an I2S input )

Maybe we can talk you into trying Linux too 😀
 
#126
WASAPI Exclusive

bcmbob said:
MrSlim/qusp, that helps a lot. I am using the WASAPI Event Style option in JRiver which reportedly is a direct link to the dac and it sounds very clean and balanced.

Would welcome additional comments but I'm in, and I hopefully will learn much more in the process.
Click to expand...

WASAPI Exclusive should be used otherwise OS mixing will be terrible and may some sample rate conversion will take place...

Interesting would be also an I/O solution O🙂

Cheers

Hp
 
#127
Have connected the OEM Combo384 Module to my MPD server 🙂
I am playing with outputs to the internal SPDIF (IRQ11), the WaveIO USB -> I2S (IRQ24) and the OEM Combo384 Module (IRQ25).

The general USB 2.0 Audio adapters / modules have generated so much interrupts that the CPU usage for USB IRQ have been in the area 2.7% to 8.3% depending on the USB port used (USB 2/3) and the USB adapter itself and the samplerate used on Intel i5 hardware platforms.
The WaveIO and the QNKTC 1.1 have comparable high interrupt levels and I have been able to reduce the CPU usage for USB IRQ to some extent, but the variation between the USB 2.0 Audio adapters when playing on USB 2.0 ports and with 44.1k/16bit have been within 5% deviation.

When I now connected the OEM Combo384 Module it generates less than 1/10 of the interrupts compared to all the other USB 2.0 Audio adapters / modules I have tested 😀

But as you can see - the internal SPDIF (possibly also direct I2S output) generates less than 1/10 of the interrupts of the OEM Combo384 Module.

My linux 3.5.2 ARM armhf setup have been tweaked for the other USB 2.0 Audio adapters and I will now start the tweaking for the OEM Combo384 Module as there may be a lot to gain when the crude start already are 10 times better than the competition - I am now running with NRPACKS=64 and the ALSA code is also modified in other respects to improve the results.
I will now do a job to find the kernel / alsa settings that works best with the OEM Combo384 Module.

Code: 
44.1k/16bit
cat /proc/interrupts 

           CPU0
  0:      28939  orion_irq  orion_tick
  7:        380  orion_irq  serial
 11:        314  orion_irq  mv64xxx_i2c
 21:      21745  orion_irq  kirkwood-i2s
 24:    3777269  orion_irq  ehci_hcd:usb1
 25:     282609  orion_irq  ehci_hcd:usb2
 29:       5538  orion_irq  eth0

Code: 
176.4k/32bit
cat /proc/interrupts 

           CPU0
  0:      14203  orion_irq  orion_tick
  7:        382  orion_irq  serial
 11:        315  orion_irq  mv64xxx_i2c
 21:      28540  orion_irq  kirkwood-i2s
 24:    1246219  orion_irq  ehci_hcd:usb1
 25:      92617  orion_irq  ehci_hcd:usb2
 29:       9180  orion_irq  eth0

Now with 176.4k/32bit the differences are a bit different, but the major difference is that the difference that was ca. 10 between the internal SPDIF and the OEM Combo384 Module - now are reduced to ca. 3..


Code: 
352.8k/24bit
cat /proc/interrupts 

           CPU0
  0:      13339  orion_irq  orion_tick
  7:        383  orion_irq  serial
 11:        314  orion_irq  mv64xxx_i2c
 21:      18058  orion_irq  kirkwood-i2s
 24:     726012  orion_irq  ehci_hcd:usb1
 25:      53891  orion_irq  ehci_hcd:usb2
 29:       5385  orion_irq  eth0

The differences with 352.8k/24bit is not really usable as in this case the internal SPDIF and the WaveIO limits at 192k as shown here:

Code: 
352.8k/24bit source
cat /proc/asound/card[COLOR="Red"]x[/COLOR]/pcm0p/sub0/hw_params

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 4096
buffer_size: 65536

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 9830
buffer_size: 131072

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 18064
buffer_size: 131072

I expect the results when I have tweaked with the OEM Combo384 Module in mind will be slightly improved...

When playing 352.8k/24bit the average total CPU usage for the ARM 800MHz single core is less than 10%.
"top" shows a average of 7% when playing with only the OEM Combo384 Module.
With all three outputs enabled and two of them downsamples the CPU usage are ca. 20%..

Code: 
top - 23:09:39 up 19 min,  1 user,  load average: 0.17, 0.29, 0.32
Tasks:  53 total,   1 running,  52 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.1 us,  2.4 sy,  0.0 ni, 92.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   1032864 total,   365308 used,   667556 free,     1948 buffers
KiB Swap:        0 total,        0 used,        0 free,   302184 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                           
 2071 mpd      -76   0 90680  36m 2760 S   7.0  3.6   3:20.94 mpd                                               
 4085 root      20   0  2644 1128  788 R   0.3  0.1   0:01.17 top                                               
    1 root      20   0  1668  620  520 S   0.0  0.1   0:00.81 init                                              
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kthreadd                                          
    3 root     -81   0     0    0    0 S   0.0  0.0   0:00.00 ksoftirqd/0                                       
    4 root     -86   0     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0                                       
    5 root     -86   0     0    0    0 S   0.0  0.0   0:00.04 kworker/u:0                                       
    6 ro
 
Last edited:
#131
MrSlim,

I have Linux on a couple boxes in an old render farm project but haven't touched them in ages. Don't know if I'll ever be a full convert but am willing and able to use Linux if needed.

I'm in the process of working out the kinks in a really bad (bad meaning vendor supplied some real garbage components) second DAC that should qualify. I ordered this TE7022L module that hopefully will show up in the next few days. Many Dac 5 users are already attempting direct I2S integration. I've been informed that this new Amanero card can also be used with the Mini2496.

It will be fun to dig in 🙂
 
Last edited:
#133
Hi, thanks for the GB.
This morning i talked with korben69 that invited me to write here how to proceed.

i propose to do in this manner. Monday i'll upload on the site a spreadsheet with the GB nicknames + prices ( 39+shipping+[VAT]+paypalfee ) then you can send me a private message with your email and i'll reply with a paypal payment request.

Thanks again,
Domenico.
 
#135
I did a quick reconfiguration (compiled a new kernel) with NRPACKS=1 and changed the ALSA configuration back to standard and then forces the the interrupt rate / CPU usage up..

This changes the differences and now the OEM Combo384 Module are less than 2 times better than the standard USB 2.0 adapters.

The OEM Combo384 Module responds very good to tweaking and it will be interesting to see what performance it is possible to get.
The initial more than 10x can possibly be tweaked to closer to 20x lower interrupt rate with the identical settings (I would be surprised if the setup I have used was the most optimal..)

Code: 
cat /proc/interrupts   

           CPU0
  0:      24623  orion_irq  orion_tick
  7:        380  orion_irq  serial
 11:        314  orion_irq  mv64xxx_i2c
 21:      49254  orion_irq  kirkwood-i2s
 24:    2116671  orion_irq  ehci_hcd:usb1
 25:    1222102  orion_irq  ehci_hcd:usb2
 29:      10086  orion_irq  eth0
 
#136
bcmbob said:
BTW: Is there a go to third party music player for Linux or is the embedded software sufficient?
Click to expand...

A lot of the Linux people are using MPD (Music Player Daemon), which uses a Client/Server approach, so that you can run the MPD client on a small, low power (read Silent) device, connected to your DAC, and then have your Music on another machine somewhere (even via ethernet) else. But you can have the Client running on the machine where you store your Music as well. There are a few small/light linux distros (voyage linux for CLI fans, and MPDPup for Noobs..) that already have MPD configured..

A few people have mentioned DeadBeef as being a nice player, and I've dabbled with Clementine, and it seems pretty nice, although I havent done any head to head SQ tests..
 
#140
HpW said:
Well, is this planned ??? otherwise I consider to skip my order...
While rigisystems.net provides multichannel & DSD & ASIO!
Cheers
Hp
Click to expand...
@HpW
You can freely skip this order. You are advertising product costing almost 10 times more. Plus, messrs Rigisystems refused to sell their product to me, almost a year ago. They even asked me to sign NDA, which I did, and still did not invoiced me nor sent their toy. Lot of international calls for nothing. I survived without them, thanks. Amanero is offering simple an I hope effective device for all my needs.

:cheers:
 
You must log in or register to reply here.
Top Bottom