[danny93]

I don't use USB DAC so can't comment, however I prefer Foxhound v1.5 (JB) so I would stick with that! Just need Siyah support now

What DAC and amp do you use with your S3?

 

[nnotis]

I'm using the Head Amp Pico DAC/amp combo.  It works on the international S3, and also the Sprint version.  I assume it works on all of the American carrier variants. 

 

[danny93]

I'm using the Head Amp Pico DAC/amp combo.  It works on the international S3, and also the Sprint version.  I assume it works on all of the American carrier variants. 

Ahh, always wanted to try that...is it much better than the HP out as I'm finding it rather good!

 

[NZtechfreak]

Thanks for the confirmation on USB DAC with Foxhound nnotis, widens the horizons for which ROMs I can try (with any luck my own Pico will arrive in a day or two).

 

[quisxx]

Anyone with both (or that has heard both) versions of the phone confirm which version sounds better?  Straight out of the Headphone out? 
Want to get a new phone to replace my n8 (it's my music device) and I'd rather get the better of the 2.

 

[nnotis]

Quote:

Ahh, always wanted to try that...is it much better than the HP out as I'm finding it rather good!

 
I did a quick comparison between the stock jack and the Pico DAC/amp using the JH13s.  The stock jack is very good for a phone.  I think the Siyah upgrades make it better yet in terms of soundstage coherence.  It's pretty noisy with the JH13s though.  It's also not in league with a good DAC/amp combo.  Going from the S3 to the Pico playing the same song, it's not subtle.  It's like looking through a lens that's almost in focus, then brought into focus.  I'll have to try using the Pico amp with the S3 DAC.  I expect it will close the gap, but still not be as accurate.

 

[NZtechfreak]

Quote:

Anyone with both (or that has heard both) versions of the phone confirm which version sounds better?  Straight out of the Headphone out? 
Want to get a new phone to replace my n8 (it's my music device) and I'd rather get the better of the 2.

 
I have an AT&T S3 (unlocked) and an International S3 at home, I will definitely be listening to both carefully at some point soon and dropping some thoughts.
 
(it would have been sooner, like maybe tomorrow, except it looks like my Pico arrives tomorrow so I'll be busy listening through that for a few days - excited to see how it drives the T5p!)

 

[nnotis]

Ok guys, here are some logs I've taken involving USB audio:
 
http://www.nicknotis.com/android_logs/
 
There are three.  One is a dmesg with the Pico connected.  I believe it worked from the get go after this restart.  The other two are logcat files of me connecting and disconnecting the Pico until it worked.  One is from the last ICS build of Foxhound, 1.4.3.  The other is from the first Jelly Bean build, 1.5.  I have no idea why the ICS one is so long while the JB is short enough for me to paste at the bottom of this post.  I had to disconnect and reconnect it once to get it working right in the JB logcat.  I was using Power Amp to all the while.  Does anyone have any insite?  I'm hoping to share these files with one of the Cyanogenmod developers, as I REALLY want them to implement this functionality.  The more I first understand the better though.  Those guys must get plastered with annoying requests.
 
 
--------- beginning of /dev/log/main
I/dalvikvm( 5944): Turning on JNI app bug workarounds for target SDK version 11...
E/Trace   ( 5944): error opening trace file: No such file or directory (2)
E/Term    ( 5944): onCreate
D/InputTransport( 5944): Input channel constructed: name='42a8add8 jackpal.androidterm/jackpal.androidterm.Term (client)', fd=44
D/Term    ( 5944): TermService started
I/TermService( 5944): Activity called onBind()
D/libEGL  ( 5944): loaded /system/lib/egl/libEGL_mali.so
D/libEGL  ( 5944): loaded /system/lib/egl/libGLESv1_CM_mali.so
D/libEGL  ( 5944): loaded /system/lib/egl/libGLESv2_mali.so
D/OpenGLRenderer( 5944): Enabling debug mode 0
I/Term    ( 5944): Bound to TermService
I/TermService( 5944): Activity binding to service
D/dalvikvm( 5944): Trying to load lib /data/data/jackpal.androidterm/lib/libjackpal-androidterm4.so 0x421aac90
D/dalvikvm( 5944): Added shared lib /data/data/jackpal.androidterm/lib/libjackpal-androidterm4.so 0x421aac90
I/libjackpal-androidterm( 5944): JNI_OnLoad
D/dalvikvm( 5944): GC_CONCURRENT freed 203K, 8% free 11022K/11911K, paused 3ms+4ms, total 29ms
I/Term    ( 5944): waiting for: 5981
D/InputTransport( 5944): Input channel constructed: name='42877420 jackpal.androidterm/jackpal.androidterm.Term (client)', fd=51
D/InputTransport( 5944): Input channel destroyed: name='42877420 jackpal.androidterm/jackpal.androidterm.Term (client)', fd=51

 

[DanBa]

A very quick look at the dmesg.txt (logcat is new for me, and it seems very interesting):
 
I’m wondering what is logged.
 
There are only USB 2.0 high-speed messages.
 
<7>[  308.485207] c0 s5p-ehci s5p-ehci: GetStatus port:2 status 001005 0  ACK POWER sig=se0 PE CONNECT
 
The Enhanced Host Controller Interface (ehci) supports USB 2.0 high speed communication between a USB 2.0 host (i.e. S3) and a USB 2.0 peripheral.
 
 
According to the S3-Pico dmesg output provided by ah_kap, his Pico is a USB 1.1 peripheral, supporting only USB 1.1 full speed communication (i.e. Open Host Controller Interface ohci):
http://dl.dropbox.com/u/24975342/dmesg.txt
 
When the USB 2.0 driver "ehci" of the S3 detects that the connected Pico is a USB 1.1 peripheral, the USB 1.1 driver "ohci" of the S3 takes over the control of the USB (full speed) communication:
 
<7>[   60.705203] c0 s5p-ehci s5p-ehci: port 1 full speed --> companion
 
and there is a problem 62.
 
<7>[   61.317389] c0 s5p-ohci s5p-ohci: urb f1be4f80 path 1 ep0out 5ec20000 cc 5 --> status -62
 
 
It should be interesting if ah_kap could use the same log tools (live dmesg lite or live dmesg ?), so that we can have a more acute comparison of the logs.

 

[NZtechfreak]

Good work DanBa, nnotis and ah_kap! I'd like clarification about which log tool to use, since I'll be able to run it on an International S3 and an AT&T one.

 

[nnotis]

Don't you think USB audio output happens after the reboot finishes?  I got the "USB connector connected" message as soon as it did.
 
Also, I used a terminal app to generate the logs.  
 
For dmesg, type: "dmesg>/sdcard/dmesg.txt"
 
For logcat, type: "su" [followed by enter; then grant the terminal root access]
then type: "logcat>/sdcard/logcat.txt"
 
I think the logcat is our best hope of capturing Touchwiz Android redirecting audio to USB.  But I don't currently speak Java, so who knows.

 

[DanBa]

The dmesg output provided by ah_kap has a lot of data about the Pico:
http://dl.dropbox.com/u/24975342/dmesg2.log
 
<6>[   18.890609] c0 usb 2-1: New USB device found, idVendor=08bb, idProduct=2707
<6>[   18.890655] c0 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>[   18.890701] c0 usb 2-1: Product: USB Audio DAC   
<6>[   18.890732] c0 usb 2-1: Manufacturer: Burr-Brown from TI              
<7>[   18.892229] c2 usb 2-1: usb_probe_device
<7>[   18.892298] c2 usb 2-1: configuration #1 chosen from 1 choice
<7>[   18.892703] c2 usb 2-1: adding 2-1:1.0 (config #1, interface 0)
<7>[   18.895630] c2 snd-usb-audio 2-1:1.0: usb_probe_interface
<7>[   18.895716] c2 snd-usb-audio 2-1:1.0: usb_probe_interface - got id
<7>[   18.896475] c0 s5p-ohci s5p-ohci: urb f1c14200 path 1 ep0in 5ec20000 cc 5 --> status -62
 
The yours has no explicit data about the Pico.
 
 
Concerning the logcat_ICS.txt, 
the USB 1.1 compliant (ohci) Pico is added to the USB bus controlled by the S3 for the first time:
 
8230 V/WiredAccessoryObserver( 8460): USB AUDIO UEVENT: {MINOR=48, MAJOR=116, SUBSYSTEM=sound, DEVNAME=snd/pcmC1D0p, DEVPATH=/devices/platform/s5p-ohci/usb2/2-1/2-1:1.0/sound/card1/pcmC1D0p, SEQNUM=1946, ACTION=add}
 
There is an error "Open failed: cannot set hw params: I/O error", because there is likely no response to the Set Configuration request sent by the S3 to the Pico:
 
8436 I/AudioHardwareTinyALSA( 2043): AudioStreamOutMultiCh::setDevice: mHandle NULL mode[0], Device[00001000] , mCardNumber[1], mDeviceNumber[0]
8437 I/AudioHardwareTinyALSA( 2043): Open: mDefaults->direction=0 device=0
8438 D/AudioHardwareTinyALSA( 2043): Channel: 2, Samplerate: 44100, Format: 0, Peroid Size: 1024, Period Count: 4
8439 E/AudioHardwareTinyALSA( 2043): Open failed: cannot set hw params: I/O error
 
 
The Pico is removed:
 
8511 V/WiredAccessoryObserver( 8460): USB AUDIO UEVENT: {MINOR=48, MAJOR=116, SUBSYSTEM=sound, DEVNAME=snd/pcmC1D0p, DEVPATH=/devices/platform/s5p-ohci/usb2/2-1/2-1:1.0/sound/card1/pcmC1D0p, SEQNUM=1952, ACTION=remove}
 
 
 
The Pico is added again to the USB bus:
 
8703 V/WiredAccessoryObserver( 8460): USB AUDIO UEVENT: {MINOR=48, MAJOR=116, SUBSYSTEM=sound, DEVNAME=snd/pcmC1D0p, DEVPATH=/devices/platform/s5p-ohci/usb2/2-1/2-1:1.0/sound/card1/pcmC1D0p, SEQNUM=1966, ACTION=add}
 
 
It’s OK: there is likely a response to the Set Configuration request sent by the S3 to the Pico:
 
8888 I/AudioHardwareTinyALSA( 2043): AudioStreamOutMultiCh::setDevice: mHandle NULL mode[0], Device[00000000] , mCardNumber[1], mDeviceNumber[0]
8889 I/AudioHardwareTinyALSA( 2043): Open: mDefaults->direction=0 device=0
8890 D/AudioHardwareTinyALSA( 2043): Channel: 2, Samplerate: 44100, Format: 0, Peroid Size: 1024, Period Count: 4
8891 I/AudioHardwareTinyALSA( 2043): before pcm_prepare
 
 
If there is a related dmesg log output like the one provided by ah_kap, the error "Open failed: cannot set hw params" should match the expiration of the timer waiting the response (i.e. 62 or ETIME):
 
<7>[   18.896475] c0 s5p-ohci s5p-ohci: urb f1c14200 path 1 ep0in 5ec20000 cc 5 --> status -62
 
 
If this diagnosis is correct, sometimes the Set Configuration request sent by the S3 to the Pico has a response from the Pico to the S3, sometimes there is no response, because some transmission parameters are likely at the limit.
 
62: ETIME:  No response packet received within the prescribed bus turn-around time.
http://www.mjmwired.net/kernel/Documentation/usb/error-codes.txt#110
"Turn-around Time: The time a device needs to wait to begin transmitting a packet after a packet has been received to prevent collisions on the USB. This time is based on the length and propagation delay characteristics of the cable and the location of the transmitting device in relation to other devices on the USB."
 
 
If we could confirm it by a dmesg log output matching a logcat output, we could ask some ALSA USB audio experts for a serious diagnosis:
http://music.columbia.edu/pipermail/andraudio/2012-April/000614.html

 

[ah_kap]

I would be glad to help. just let me know which logs you would like. The dmesg logs are for bootup logging and logcat gives you realtime system messages.

tapatalk'd

 

[DanBa]

Your dmesg output is very informative, as well as the logcat output provided by nnotis.
 
It should be interesting that you and nnotis log the same trace using the same dmesg tool and the same logcat tool:
. connect the Pico to the S3
. if it doesn’t work, disconnect the Pico
. reconnect the Pico
. if it doesn’t work, disconnect the Pico
. reconnect the Pico

 

[seeteeyou]

.