USB Asynchronous DAC?

I'm trying to connect to a USB DAC.
Does anyone know if this is possible?

I've installed the software to my CuBox i4pro using the rpi complilation on an openelec image, and its all up and running fine.
I can connect from my MAC using the client, and can see / use the USB port from OSX.
Thumbdrives are certainly working fine.

When I connect the DAC, the device pops up in the sound options in preferences, exactly as if connected directly, so I was sure I was onto a winner.
But alas, although I can play music from iTunes (or it shows playback progress) I get no sound, or more accurately, I get a fraction of a second of sound, and then silence from that point onwards.

I also tried with some 'audiophile' software on the mac that can auto switch bit/sample rates on the DAC to match the music being played.
This software also sees the DAC, and even switches sample rates correctly (i can see the correct lights popping up on the front) but it actually refuses to actually start any audio playback at all.

Any help appreciated.
Antony

#2

Sorry, should have included the log output...

Wed Jan 7 22:07:14 2015 LOG_INFO Using default configuration /storage/virtualhere/config.ini
Wed Jan 7 22:07:14 2015 LOG_INFO Serial:d063b4007d58
Wed Jan 7 22:07:14 2015 LOG_INFO Server licensed to=unlicensed max_devices=1
Wed Jan 7 22:07:14 2015 LOG_INFO Using large URB's
Wed Jan 7 22:07:14 2015 LOG_DEBUG TCPServer starting...
Wed Jan 7 22:07:14 2015 LOG_INFO TCPServer bound to port 7575
Wed Jan 7 22:07:14 2015 LOG_DEBUG TCPServer (7575) started
Wed Jan 7 22:07:14 2015 LOG_INFO Found Full speed device [21b4:0081] "AudioQuest inc., AudioQuest DragonFly" at address 21
Wed Jan 7 22:07:15 2015 LOG_INFO Callback: VirtualHere USB Sharing_vhusb_tcplocal Name Registered
Wed Jan 7 22:07:20 2015 LOG_DEBUG 192.168.1.50 connected
Wed Jan 7 22:07:31 2015 LOG_INFO Device 21 BOUND to connection 1

^^ playback happening in iTunes up to here but no audio or errors being logged ^^

Wed Jan 7 22:08:45 2015 LOG_WARNING Warning, there are outstanding URBs while endpoint 0x01 is clearing halt
Wed Jan 7 22:09:01 2015 LOG_WARNING Warning, there are outstanding URBs while endpoint 0x01 is clearing halt
Wed Jan 7 22:09:01 2015 LOG_WARNING Warning, discard urb(0x548e40) for device 21b4/0081 failed , Invalid argument (22)
Wed Jan 7 22:09:01 2015 LOG_WARNING Warning, there are outstanding URBs while endpoint 0x83 is clearing halt
Wed Jan 7 22:09:01 2015 LOG_WARNING Warning, discard urb(0x537880) for device 21b4/0081 failed , Invalid argument (22)
Wed Jan 7 22:09:01 2015 LOG_WARNING Warning, discard urb(0x5469a0) for device 21b4/0081 failed , Invalid argument (22)
Wed Jan 7 22:09:01 2015 LOG_WARNING Warning, there are outstanding URBs while endpoint 0x01 is clearing halt
Wed Jan 7 22:09:20 2015 LOG_WARNING Warning, there are outstanding URBs while endpoint 0x01 is clearing halt
Wed Jan 7 22:09:25 2015 LOG_WARNING Warning, there are outstanding URBs while endpoint 0x01 is clearing halt
Wed Jan 7 22:09:25 2015 LOG_WARNING Warning, discard urb(0x538140) for device 21b4/0081 failed , Invalid argument (22)
Wed Jan 7 22:09:25 2015 LOG_WARNING Warning, there are outstanding URBs while endpoint 0x01 is clearing halt

^^ these popped up attempted to start / stop playback using the audirvana software. playback would not start at all ^^

thanks again

#3

Yeah i have not implemented "isochronous" transfers on mac. I haven't figured out yet how to implement it because osx is much more specific about latencies than in windows and Linux. Running USB over IP changes latencies which doesn't matter for windows or linux, but with osx it continually tries to resynchronize the stream via frame numbers which I haven't yet figured out how to simulate correctly. So there is no way it will work on osx at the moment.

#4

That's fair enough.
I wonder if that's why osx is often perceived to be better for usb audio due to stricter management of the bus.

Do you think it'll work from windows then?
I'll certainly give it a go later.

Very cool software by the way :)

#6

I can again connect to the DAC via virtualhere (x64) client, but in windows the device doesn't even appear as an available sound output device.

In device manager I can see the virtualhere USB root hub, but under device status I see:

"This device is working properly.There is a secondary device connected to this hardware that Windows cannot identify because it does not have a valid hardware identification number.

For assistance, contact the hardware manufacturer."

OSX is actually closer than windows to getting it working :(

Any ideas?

#7

Can i get remote access to port 7575 on your pi? I can connect from my office and see if i can trace the problem. If so please email mail [at] virtualhere.com (mail[at]virtualhere[dot]com)

#8

Many thanks for the latest release.

I am now able to connect to the device properly from windows.
It installs drivers as if plugged in directly, and it then appears as a sound device in control panel.
Looking good.

Unfortunately it doesn't work very well.
Constant skipping, and pops and clicks as music is being played via it, which doesn't happen when the dac is connected directly to the windows machine or from the CuBox itself.

I don't believe its network related, both machines are connected to a gigabit LAN, which I guess should be more than enough for class 1 usb audio bandwidth (I was even hopeful to get a class 2 device up and running using virtualhere originally).

Any more suggestions?

#9

Its almost certainly a latency issue, your DAC is probably stricter with timing issues.

(I do my isochronous testing on using a logitech webcam for video, and for audio a logitech usb lapdesk with a speaker, to see the performance and verify memory usage etc. lapdesk audio works fine over wifi, webcam jumps a bit at high resolution, lower resolution fixes this)

Take a look at "top" when running on the cubox, see what kind of cpu usage you are using.
Could you try turning down the quality of the sound on your dac. Just for testing to see if you get less clicks etc. It should easily handle 16-bit 44khz without skipping.

#10

these artefacts were introduced at 16/44.1, but I'll certainly take a look at CPU usage and let you know.

#11

My device is this: http://hifimediy.com/usb-dac2. After adding the custom event handler it doesn't return error -1 anymore. On Windows client it shows up as "SA9023 USB Audio (In use by you)" but Windows lists is in device manager as "USB Composite Device" with yellow triangle and status says "This device cannot start. (Code 10)". Any idea if there's a workaround? The DAC works fine on my Ubuntu machine (on which I run the server too).

#12

Im guessing you added an onReset event handler. I suspect that it needs to be reset for the SA9023 to initialize its hardware before use. Usually with this sort of more technical audio hardware they require tighter timing constraints via the usb protocol which is not supported under virtualhere because the network introduces latency which is unavoidable.