Hi everyone,
Thought I would post about an Android issue that is bugging me - the fact that despite USB Host functionality being present in ICS, USB DACs (digital audio converters, external sound cards if you will) do not work with our devices .
If they did work then we could use relatively cheap USB DACs with our Android phones and enjoy great music sound quality, no matter which cheap DAC/DSP the manufacturer has seen fit to include. Ever since I sold my Galaxy S, which has an excellent Wolfson DAC and can produce awesome sound quality with Voodoo Sound, the sound quality of my subsequent devices has rankled. Now with ICS this is a simple software fix, which makes it all the more irritating (someone has managed to add support for these in a Nook Colour kernel that works with CM9). To be honest I'm seriously considering buying an iPhone for the first time ever because they have this functionality out of the box.
Fortunately there is something we can do about this besides making ineffectual unhappy noises and waiting for customs ROMs etc to fix this - vote the issue up here: http://code.google.com/p/android/is...rs&colspec=ID Type Status Owner Summary Stars
To vote just star the issue.
This issue needs ~1150 votes to enter the top ten, which doesn't seem a big ask given the hundreds of millions of Android users out there... (it's got 66 votes so far today and risen 16 places up the issues ladder).
Please star this and share this out to your social networks - help save me from having to continue think about getting an iPhone!
I also posted about this issue at my blog, if you were planning to share it out over your social networks that might be a better thing to link to:
http://www.androidnz.net/2012/02/android-usb-host-for-audio-devices-fail.html
code.google link does not work.
+1!
I would also really like to see this implemented. Shouldn't be too difficult for them, methinks? The nook already seems to be able to do 24/96 with a USB DAC using a standard USB audio module. Apparently, with the correct ALSA driver we could also do 24/192, even!
ps. Correct url to vote (sans http prefix) is here:
code.google.com/p/android/issues/detail?id=24614
^ I are n00b so can't link, sorry.
Add star near the comment box at the bottom of the thread.
Voted for it since the first week. Hoping i can finally ditch my ipod once and for all.
Working link?
Sent from my GT-I9100 using Tapatalk
guttsy said:
I would also really like to see this implemented. Shouldn't be too difficult for them, methinks? The nook already seems to be able to do 24/96 with a USB DAC using a standard USB audio module. Apparently, with the correct ALSA driver we could also do 24/192, even!
ps. Correct url to vote (sans http prefix) is here:
code.google.com/p/android/issues/detail?id=24614
^ I are n00b so can't link, sorry.
Add star near the comment box at the bottom of the thread.
Click to expand...
Click to collapse
No, it's a major ***** for them to implement - ALSA is evil.
Getting audio routing to work properly on a device with fixed hardware is enough of a pain as it is.
Handling audio routing that changes for 3280348230 different peripherals would be an utter nightmare for Samsung.
While I agree it would be a cool feature, it's definately something hard. Just look at how hard it was for us to make audio working properly on Ice Cream Sandwich. While some Alsa could work, all devices have their own controls and way of working, so it's really tough to make it work for all at once (which is probably why Google doesn't support it).
First post updated with working link!
In relation to this being difficult, doesn't seem that difficult since it's been done already (the Nook fix was not specific to the E7). Surely doesn't need peripheral-specific support, only needs to be able to send audio out via USB on the host device? The iPhone doesn't specifically support any particular peripherals either...
Anyways, thanks to those who have voted, over 100 extra votes now and climbed 24 places.
Apparently there's a test-build kernel around that would support USB DAC for GB (yes I know we are talking about ICS here)
For those interested go check out the post by pongster
http://forum.xda-developers.com/showpost.php?p=22265282&postcount=9844
Starred.. i really wish to see iRig sorta of hardware being supported
Sent from my GT-I9100 using XDA App
Elythor said:
Apparently there's a test-build kernel around that would support USB DAC for GB (yes I know we are talking about ICS here)
For those interested go check out the post by pongster
http://forum.xda-developers.com/showpost.php?p=22265282&postcount=9844
Click to expand...
Click to collapse
Interesting! Just been reading there... I would imagine custom ROMs and kernels will support this long before Google
Still, important to try and raise the issue with Google, would rather not wait for x-feature to be ported b ydevs with every new Android device.
Entropy512 said:
No, it's a major ***** for them to implement - ALSA is evil.
Getting audio routing to work properly on a device with fixed hardware is enough of a pain as it is.
Handling audio routing that changes for 3280348230 different peripherals would be an utter nightmare for Samsung.
Click to expand...
Click to collapse
I was thinking... some devs could get this thing to work in their custom ROMs on some devices, like Nook color for example. Why should be so hard for Google to implement this? I have a tablet, and could make ALSA recognize my DAC with appropriate libraries, but route audio to the DAC is imposible, tried to mess asound.state, alsa.conf, etc...
Seems to be something hard, but there are devs who could get it working.
If the problem is that each DAC has its own protocol and settings, and that accommodating every powered DAC would be too difficult, then wouldn't the next step be to ask a few specific companies to design and build Android DACs around a fixed set of values, commands and so forth, and to introduce them on a very small scale at first -- so that, while not every DAC worked with Android, a few specific ones did? That's what a certain fruit company did with the Wadia 170i and the Cipher Labs AlgoRhythm Solo.
Reignogleph MMXI said:
If the difficulty is that each DAC has its own protocol and settings, and that accommodating the massive variables inherent in including every powered DAC would be too difficult, then wouldn't the next step be to ask a few specific companies to design and build Android DACs around a fixed set of values, commands and so forth, and to introduce them a scale that small at first -- so that not every DAC works with Android, but a few specific ones do? That's what a certain fruit company did with the Wadia 170i and the Cipher Labs AlgoRhythm Solo.
Click to expand...
Click to collapse
I think the guys from Wadia/BA went to the Android SD requesting Google to help them (for the Droid & Captivate ) but they got a naked bird instead..remember that Google only recently have launched the music store...
I think audio hardware is one of those non standard things across android platforms and getting the audio -usb dac protocol to work across all devices would prove difficult if not impossible for stock android.
But yes, it's a feature id definitely want to see implemented. But I think the devs might have to take on this one.
Sent from my samsung galaxy s2 using tapatalk
This has already been accomplished on the Nook. It's not difficult.
01010001 said:
This has already been accomplished on the Nook. It's not difficult.
Click to expand...
Click to collapse
If it's not hard, please do us all a favor and implement it yourself.
Sent from my GT-I9100 using XDA
So out of curiosity, if we did indeed have ALSA working with a USB DAC, would that bring the audio latency down to near realtime speeds?
If there's one are that iOS is superior to Android it's with low latency audio performance, and that's why you don't really see any softsynths or guitar processing apps for Android, sadly.
Lord Tim said:
So out of curiosity, if we did indeed have ALSA working with a USB DAC, would that bring the audio latency down to near realtime speeds?
If there's one are that iOS is superior to Android it's with low latency audio performance, and that's why you don't really see any softsynths or guitar processing apps for Android, sadly.
Click to expand...
Click to collapse
Good question.
Would be another benefit. Even if I care only for external DAC's with superior sound quality, I'm sure that there are people waiting for this
Sent from my GT-I9100 using XDA
You galaxy sII people are lucky, cyanogenmod supports audio out via usb. Still no real love for the galaxy nexus
Related
Is it possible to get audio playing over the USB port from the HD2?
With the iPhones, the audio market have a line out dock which takes the proprietory plug the iPhone uses to charge and sync and outputs to a 3.5mm jack. This bypasses the internal amplification circuitry so that you can use an external amplifier for a better signal to your earphones/headphones/speakers of choice.
I was wondering if it was possible to do this with the HTC HD2.
Can anyone offer any insight?
I'm no expert however from what I know, I think the iPhones dock connector has more than just regular USB connections inside. It may have some audio connections and possibly even a video connection. So I'm guessing the audio actually gets sent through that rather than via USB.
However, I imagine that you could send audio via USB but at a guess I think it might require a processor is some description at the other end to take the audio and send it to the speakers.
This may be totally in the wrong direction but I believe it is probably along these lines
Sent from my Nexus S using XDA App
It's most certainly a question for those of the XDA Community who know the ins and outs of the USB port and what it can actually do.
I'd love to think that it is possible. Whilst I'm happy with the output of the HD2 sound quality-wise, the mere thought that it 'could' be better intrigues me.
Can anyone help explain if it can be done, how it can be done or if it can't be done, why it can't be done?
Just to get a bit more info, where were you thinking the USB audio would be used? Like through a PC and then to it's speakers, or do you have some MicroUSB audio dock thing? I imagine whether it is possible or not depends on where you want the audio to go to.
I imagine if it was through a PC then it would be a matter of software, and therefore be possible. But I don't know about a dock situation.
Jonathon Grigg said:
Just to get a bit more info, where were you thinking the USB audio would be used? Like through a PC and then to it's speakers, or do you have some MicroUSB audio dock thing? I imagine whether it is possible or not depends on where you want the audio to go to.
I imagine if it was through a PC then it would be a matter of software, and therefore be possible. But I don't know about a dock situation.
Click to expand...
Click to collapse
From the HD2's USB port into a portable amplifier (3.5mm jack) then onto a pair of IEM's.
I guess it is also plausible that it could go from the HD2's USB port to a USB DAC/Amp then out onto a pair of IEM's but that kind of DAC/Amp doesn't come cheaply and then there's a whole driver issue to contend with, possibly.
This is strictly to improve audio in a portable capacity, as iPhone users seem to have been able to do for quite some time.
Alright then, beyond my scope mate sorry we need other developers to check this out I think.
Anyone?
Sent from my Nexus S using XDA App
Thanks Johnathon.
Hopefully someone else will reply to this. Plenty of views but no chatter.
Yeah, I'm sure you will find someone though! It is the HD2 section after all more than enough devs in these parts
Sent from my Nexus S using XDA App
I do not think it would be, like the DAC isn't it? why not just use the Bluetooth A2DP?
growlye said:
I do not think it would be, like the DAC isn't it? why not just use the Bluetooth A2DP?
Click to expand...
Click to collapse
I do not understand your question and do not see how Bluetooth A2DP would help at all.
Final bump
I know that CyanogenMod9 allows audio out over usb on some phones.
I'm really interested to know too so have asked the Q in the android forum: http://forum.xda-developers.com/showthread.php?p=22920882#post22920882
Fingers crossed...
Bumping
There are many more people interested then it shows here.
I know the following must be in place before USB class audio will work:
ALSA drivers in the kernel
USB host
USB OTG
and if all of that is in, then in theory USB audio should work.
Jelly Bean makes this official, which is nice. but many of us still use CM7, especially Tyween Typhoons, for stability, and it would be awesum if it worked in there, although to be honest I am waiting for the final CM7.2 before I test again.
Hi Devs.
After doing a little research, its seems that USB audio support is enabled in the S3 kernel. There seems to be a fair bit of support for implenting this feature accross a range of devices.
I also note that the cheap C-media chips are recognised by the S3 kernel. So I'm going to buy one, as they are cheap as chips. I realise the sound quality won't be up to much but its a step in the right direction, as I don't currently have and other USB audio devices.
So, I fancy a little kernel compiling. I have done this on linux systems many years ago and I still compile the odd program when I have to. There seem to be some kernel compiling good guides, but I am wondering if anyone else is looking into this feature, or can suggest a good place to start. Is it worth starting with an S3 kernel, (I guess not) or should I start from scratch, or another kernel I like? Anything I compile and test will have cifs support, as its something I can't do without.
I also see the Glados kernel for Nexus already has USB audio support.
Obviously I'm aware of the emmc erase issue, so starting with sources that disable this feature would be a good idea.
Am I completely mental or is this worth having a go at? I'm willing to wait a while if its too dangerous to try until Samsung release a fix for the SuperBrick.
I'll admit I'm rusty, but I have successfully complied kernels in the past.
Any comments will be graciously be recieved!
OK, no love for USB audio. Looks like I'm on my own then!
+1 for USB audio
Galaxy note Paranoid Android 1.7ghz goodness
audio over usb
Galaxy Note has USB audio support too. Take a look at Samsung EDD-D1E1 Dockingstation for Samsung Galaxy Note. it's with Line-Out for external speaker.
The note doesn't supply much power in the USB OTG configuration so may need to be an externally powered unit, or running via a hub.
As NBLive says, the car dock has a USB --> 3.5mm option which works fine with the Note (I was using it about 2 hours ago), so the support is there, we just need driver support for "generic" units.
It's also pretty much a non-issue for the S3 anyway as it's got the good Wolfson DAC rather than the crappy Yamaha (iirc) one the Note has.
NBLive said:
Galaxy Note has USB audio support too. Take a look at Samsung EDD-D1E1 Dockingstation for Samsung Galaxy Note. it's with Line-Out for external speaker.
Click to expand...
Click to collapse
As I recall it the dockingstation only have analog audio (not usb audio but it might use the same connector), I have the dock somewhere, will check when I find it.
To OP, you are absolutely not alone on this one, It is one of the most requested features on Android (link).
There are also a few threads in the forum.
slinbin said:
As I recall it the dockingstation only have analog audio (not usb audio but it might use the same connector), I have the dock somewhere, will check when I find it.
To OP, you are absolutely not alone on this one, It is one of the most requested features on Android (link).
There are also a few threads in the forum.
Click to expand...
Click to collapse
You are correct. The dockstation is just a usb connector with the sense pin 4 having a resistor of a certain value connected to ground, telling to phone to output analogue audio to the data lines of the usb circuit. This is similar to how the phone senses a USB OTG or MHL-HDMI cable.
What I'm talking about here is USB audio device driver support at the kernel level. Currently its not compiled into the Note's but is supported for a limited number of devices in the galaxy S3 kernel. Simplistically put, the phone doesn't have the drivers.
I've looked around at various config files in the Note and am now wondering if SPDIF audio can be outputted over USB. However, I could be wrong as the there is a lot of ancient crap left over from linux configs from 10 years ago, for instance, config files for Turtle Beach sound cards!
The other option is to use the MHL-HDMI adaptor and then an HDMI to digital audio but that's a bit clunky and given that the S3 can do what we want, it shouldn't be too hard.
The advantages of this are a higher quality audio, multi channel output from DTS surround Vidoe and audio and stereo line in recording. Although android is not the greatest OS for audio work due to latency issues, USB audio support is a step towards iphone like audio recording/mixing and effects work. The S3 can also support much higher Bit rates and sampling frequencies, upto 24bit/192kHz. Far better than CD quality, let alone mp3.
Many people can't hear or don't care for higher quality audio. I for one can tell the difference between mp3 and CD or FLAC. To be honest, listening to mp3's can sometimes be painful to my ears. If you can't hear the difference, imagine being forced to listen to everything on an AM radio!
Sorry to blabber on lol
knightnz said:
The note doesn't supply much power in the USB OTG configuration so may need to be an externally powered unit, or running via a hub.
As NBLive says, the car dock has a USB --> 3.5mm option which works fine with the Note (I was using it about 2 hours ago), so the support is there, we just need driver support for "generic" units.
It's also pretty much a non-issue for the S3 anyway as it's got the good Wolfson DAC rather than the crappy Yamaha (iirc) one the Note has.
Click to expand...
Click to collapse
Reports are coming in that the Woflson DACs are not sounding so good. The Car docks do not have any kind of DAC in them.
+1, This would be great if I could use my Fiio E17 on note!
Sent from my GT-N7000 using XDA
I can build a kernel with that for you.. I guess. if nothing fails to build.
I'm using a custom kernel that I've had built for myself. Its basicly a Speedmod kernel with some modules (USB ethernet).
Do you have any chip in mind? I can make a CWM package to you.
It will be a Speedmod kernel with the modules.
Remember that Its not a kernel module thay you Want. I don't know if Android will recognize it and play out thru it.
mdrjr said:
I can build a kernel with that for you.. I guess. if nothing fails to build.
I'm using a custom kernel that I've had built for myself. Its basicly a Speedmod kernel with some modules (USB ethernet).
Do you have any chip in mind? I can make a CWM package to you.
It will be a Speedmod kernel with the modules.
Remember that Its not a kernel module thay you Want. I don't know if Android will recognize it and play out thru it.
Click to expand...
Click to collapse
Thanks a lot, saves me setting up a dev environment. I'm still struggling to get a stable laptop and I really don't wanna start doing critical stuff with it (fingers crossed, no hard video hangs with ubuntu 12.04!)
Try compiling for the cheapo c-media chipsets. They are only £1.50 and one is in the post. Think the driver is called cs4281 or something similar and are used in loads of crappy speakers/headphones.
I have read reports that these are recognised under dmesg on the S3.
If this is successful, they I might buy a better USB DAC.
I wonder if the yamaha chip can be persuaded to output spdif over usb. This would enable a wider (and cheaper!) range of DAC's to be used. There is support for ie958 under alsa in android........just a thought.
EDIT: hold off till I get the usb sound device. Some of them are using newer chipsets. I will plug it in to a linux machine and let you know what it is.
I would really benefit being able to plug my YETI microphone into my note for journalism. I remember vaguely looking at it a while ago where people were saying that you need to edit a file (to fake drivers or something) but in the end they were waiting on Google to release audio USB drivers.
I'm only a noob so take what I say with a pinch of salt.
+1
I would love to be able to plug a USB mic into the Note for audio recording.
I don't know if it will solve the latency problems that Android has, but the better audio quality would be good.
reconchrist said:
I would really benefit being able to plug my YETI microphone into my note for journalism. I remember vaguely looking at it a while ago where people were saying that you need to edit a file (to fake drivers or something) but in the end they were waiting on Google to release audio USB drivers.
I'm only a noob so take what I say with a pinch of salt.
Click to expand...
Click to collapse
richlum said:
+1
I would love to be able to plug a USB mic into the Note for audio recording.
I don't know if it will solve the latency problems that Android has, but the better audio quality would be good.
Click to expand...
Click to collapse
I currently have a logitech usb mic to test with also but I have to stress, this testing is just intitial driver support. There probably won't be any programs that will be able to select inputs for recording. I may be able to write a script to select an alternative input device but we are still quite far from this goal.
Glad to see things gaining traction. Hopefully google and samsung are already far ahead and will release something soon.
I would like to see the S3 sources though!
I've been looking through the S3 kernel source. Under /drivers/usb/gadget/ there a various drivers and headers called f_audio.c, u_audio.c, u_audio.h.
Also the Kconfig file details on how to implement these drivers into the kernel. It seems to me that if these can be compiled sucessfully for the Note kernel, it should just be a matter of changing alsa config files to at least initially get audio input/output support for usb audio devices.
Can't wait to have a go!
Someone else will have to write an app to do the device selection in a nice way. That side of things is beyond me.
Downloading the Note kernel source to compare.
Do you know if android uses any sound manager?
My worst fear is that we can't play sound thru it.
Getting a USB device to be recognized by the kernel is easy. All I need to do is to build a kernel with that extra module.
Load the module and boom. Kernel should recognize it.
How about Android sets his output to that new device?
-Zage- said:
+1, This would be great if I could use my Fiio E17 on note!
Click to expand...
Click to collapse
That's the kind of cake I wanna eat.....
Have your music in one place listen to lowQ when thats enough and highQ when you want that (with a extra box on the side, but the music and control stays in the Note).
I feel like if android natively supported exterior USB audio better. The app potential would be huge for audio out apps and simple 2-8 track recording apps among other things
Galaxy note Paranoid Android 1.7ghz goodness
Always looking to improve sound quality. Thanks for thinking outside the box. Hope it all works out in our favour. Suck it iphones xD.
Dynamano said:
Always looking to improve sound quality. Thanks for thinking outside the box. Hope it all works out in our favour. Suck it iphones xD.
Click to expand...
Click to collapse
Whilst I don't like Apple products at all, audio is the one area that an Android user just hangs his head in shame when someone with iOS shows them what they can do on their iphone or ipad.
I'm hoping Android gets a low latency solution soon, but even then, it will be a long way till Android if close to being on par with iOS for audio apps.
---
I am pretty certain that you would not need to underoot, even. I believe (and please correct me, aficionados, if I am wrong), the Nexus as a 5th low voltage processor that works when no intensive tasks are being performed, thus increasing battery life.
Deafcyclist said:
...payment register (using credit card swiper like Square or Intuit)...!
Click to expand...
Click to collapse
Has anyone even tried this yet? I believe you need a speaker Jack that has both speaker output AND Mic input to use these devices.
The Nexus does not have a Mic input on the speaker Jack.
Sent from my Nexus 7
Deafcyclist said:
screen out monitor, remote trigger, intervalometer, digital portfolio
Click to expand...
Click to collapse
Tell me where I can get a compatible cable for a 5D Mik II and I'll let you know
---
Deafcyclist said:
Looking at http://dslrcontroller.com/devices.php , it seem that you either only need an OTG adapter or in case of a similar set up with the asus transformer (Asus made the Nexus 7, right?), a special ASUS Usb cable (with a micro to mini usb adapter).
Any more than that, I can't help you as I don't have the dslr controller app, Nexus 7, or the cables.
Click to expand...
Click to collapse
I'll order up some cables on eBay and let you know later this week.
I've been aware or the ability to control dSLRs via android and have done so using EOS Utility+Laptop
but with screen resolutions being what they were with droid devices I didn't see the point.
Now I have the N7 I can see how it may be very useful and be far superior to EOS utility+ bulky Laptop.
---
There is a lengthy thread for the DSLR Controller here: http://forum.xda-developers.com/showthread.php?t=1202082
People have got it working with an OTG cable, without rooting.
I'm waiting for my OTG cable (should be here Monday/Tuesday)..
Linking to a 7D, what are you guys shooting ?
---
T4i ? nice!
If you didn't find it already take a look here, a whole bunch of info http://photography-on-the.net/forum/
Deafcyclist said:
... payment register (using credit card swiper like Square or Intuit)
Click to expand...
Click to collapse
krelvinaz said:
Has anyone even tried this yet? I believe you need a speaker Jack that has both speaker output AND Mic input to use these devices.
The Nexus does not have a Mic input on the speaker Jack.
Click to expand...
Click to collapse
This apparently is not accurate. There is a Mic, but the right speaker/mic combination needs to be used and a lot of apps don't apparently work while a few do.
Chances are, there will need to be some updates on this, most likely on the app side to get this to work properly. One would think that the credit card swipe devices would test it and tweak their apps to work. Think that using a smart phone might be a better choice since it has 3G/4G data and the Nexus 7 doesn't and would require a network connection to transmit the data though. Dont need a lot of size to do a credit card transaction.
So not to dis on the Nexus 7 at all but as a Photographer myself I would think you'd be better off with one of the Transformers for something like this. I just have a TF101 but its got a nice big screen and probably more than enough battery power with the keyboard dock for you to play with for a full day. Something like the higher resolution models out now would be even better.
The way I shoot weddings or even in the studio, it would be insanely cumbersome to move the subject, adjust the tripod and go to the tablet to take the pictures. I would end up using it mostly for previews. If you just want previews, since you have a camera with an SD slot, I'm pretty sure you're life would be MUCH easier just using a Eye-Fi card that syncs with the Nexus / Tablet by dropping JPG's into the gallery for you as you shoot (keeping the RAW's on the actual card assuming you shoot RAW).
The other thing to keep in mind with the Nexus 7 in your grand scheme of things is it is a really bad choice for displaying your portfolio due to the lack of on board storage and screen size. On a 10 inch table a landscape image looks small but barely passable in portrait and visa versa, on a 7 inch I wouldn't even consider it passable and would need to format portrait or landscape portfolios = more work for me!
Last but not least, just use your phone for CC transactions, it's always with you and always has a network connection and stuff like Square should just work without having to Jerry Rig anything.
Not trying to change your mind on anything, just some insight form a like minded photographer. Honestly with the exception of the Eye-Fi for previews by the time you mash together a workable solution you'll probably hate having to set everything up and find yourself working around a new set of self imposed limitations rather then doing what photographers like to do, taking good pictures.
---
Hi guys,
there is a lot of speculation on this matter,
and it seems that after the gs3, note 2 and other devices release, the interest of this project by the developers vanished.
I want to know if there is anyone that is making progress with this matter.
Maybe some custom rom that i'm not aware of,
maybe some kernel that i'm not aware of.
At the moment it seems that the situation is really bad.
I've found an app on the store that states that "Samsung blocks usb audio devices on the S1, S2, and note 1". But they have plenty of stock phones and tablets that work with the app for a usb audio output.
I really hope that someone is trying to do something for us.
Thank you very much all
I remember there was a lot of talk about this when details of ICS first started getting leaked cause it supposedly had support for USB audio naively coded into it. I think a few people tried with a few devices but didn't have much luck and it wasn't really investigated very well afterwards (someone correct me if i'm wrong, i'm going on memory from a year ago). When the S3 dropped people tried it with a range of USB DACs and it works with many, but not all.
I've not seen anything new about the subject on here for a while, i've been looking out for it and i'd have expected it to have been big news.
Anyway, these people over at head-fi seem to think the S2 is compatible and recognises the USB audio output, but will not output through that channel, and that it just needs some developer to code something to force audio through that channel. Thread is now cold. I've got limited coding experience and it doesn't sound like the hardest job, which makes me think theres more too it. Waiting to head if someone else knows anything.
maybe I don't understand correctly what USB Audio really means, but the original Samsung car holder outputs analog audio when phone is plugged into USB slot.
crisagatie said:
maybe I don't understand correctly what USB Audio really means, but the original Samsung car holder outputs analog audio when phone is plugged into USB slot.
Click to expand...
Click to collapse
I know very well the post on head-fi you mention as i'm a contributor.
The problem of the USB audio is a different problem from the car holder you mention.
What we basically want is an output of the DIGITAL audio from the usb, because we want to bypass the internal audio DAC, because it is really poor, and the output impedance of the galaxy s2 is terribly high.
If we can achieve the DIGITAL audio through usb we could convert and amp our sounds via an external DAC/AMP bypassing the internal DAC of the Galaxy s2, the Yamahaa, wich is really crap.
At the moment it is impossible for the galaxy s2 to achieve this because samsung blocks that.
The galaxy s3 is capable of this, and no one is coding something or is interested to achieve a result for our phone.
I also think that this post will go deep down the forum and goodbye.
Sad enough
Doesn't work & you hit the nail on the head; no developer will touch it. Many have been asked over the past 18 mths or so, a few have had a proper look & all have gone 'nope'. Too many proprietary Samsung blobs involved, you mess with one blob you break something else, etc, etc.
As the phone has been superceded by the S3 months ago now, the chances of finding a developer to get this done is pretty much zero. Don't bother offering money, that won't help. That one has been tried here as well; at one stage we had pledges totaling in the high 100's of $ & that did pique anyone's interest.
Better off getting an S3 if you want that kind of thing, and chances are you wouldn't need it with the S3 anyway because it has a Wolfson DAC & the sound is probably pretty reasonable. I haven't auditioned it myself as I have a good dedicated media player, which frankly is probably the WTG if you're really unhappy with the sound out of the SGS2.
Check out this item I found on eBay:
http://pages.ebay.com/link/?nav=item.view&id=251063674228
Sent from my GT-I9100P using Tapatalk 2
Yes, there is support for USB Dock Audio, but how does it work? I bet the dock itself doesn't have any DAC or other audio processing modules so maybe it's just MHL supported? But in other way, sound through MHL will be digital, and the output in dock is analog jack.
Any ideas?
I know the Audio works in Car Dock, Problem is i am also currently looking into the software i had on previously. Some say its The Kernel , unfortunately i flashed my phone so many times i am not really sure of the Firmware / Kernel. Rest assured if i discover i will share.:good::cyclops:
CapuozzoCantina said:
Hi guys,
there is a lot of speculation on this matter,
and it seems that after the gs3, note 2 and other devices release, the interest of this project by the developers vanished.
I want to know if there is anyone that is making progress with this matter.
Maybe some custom rom that i'm not aware of,
maybe some kernel that i'm not aware of.
At the moment it seems that the situation is really bad.
I've found an app on the store that states that "Samsung blocks usb audio devices on the S1, S2, and note 1". But they have plenty of stock phones and tablets that work with the app for a usb audio output.
I really hope that someone is trying to do something for us.
Thank you very much all
Click to expand...
Click to collapse
i don't understand everything that was written in here.
i'm very badly wating for the usb audio support of the original Samsung Galaxy S2 Car Holder/Dock.
i can't imagine why it takes so long or is so complicated to implement this feature when it worked back in cm9 like a charm.
A sullution... (http://forum.xda-developers.com/showthread.php?t=2029728) but is there a kernel compatible??
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
mikeserv said:
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Entropy512 said:
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Click to expand...
Click to collapse
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
mikeserv said:
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Entropy512 said:
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Click to expand...
Click to collapse
Wow. Strong words. You consider PulseAudio an existential bane, huh? Can I ask what sound daemon you use instead? I suppose it's possible you do without. Though it seems OSS is entirely deprecated, ALSA can still provide minimal functionality without a user-space management daemon if necessary, but without some extensive and, at least to me, seemingly esoteric initial configurations, good luck handling even a lasting volume adjustment without root access (or be in the "sound' group, I suppose), and should you have occasion to simultaneously offer two applications sound privileges... Sorry, grinding my teeth again.
Anyway, I didn't much like PA at first either, but I wanna say my first encounter with it was Ubuntu 7.10 or so, or thereabouts. I've since adopted the greener pastures offerred by several other distributions, less brown anyway, but PulseAudio is a fairly static component of my sound system as configured by default by distro maintainers no matter where I wander. Even on systems I build up myself from very little, when PulseAudio is included it tends to be one the things I have to consider least as trouble goes. The plugin support is very extensive these days as well.
When PulseAudio is combined with Bluez for instance, it can emulate almost all of the headset profiles, to include a telecommunications headset, and can easily record from this stream or any other because every one of PA's sources can be easily multiplexed. It's fun, and very powerful. PA can do on cheap or even no dedicated hardware at all what Airplay only aspires to. And these days, it even makes it easy. It's a true sound server, and while it can be utilized simply enough with Android satellite clients if you set it to emulate Airplay, to serve a multi/unicast, and/or to emulate the DLNA protocol, even this impressive scope of functionality is much diminished when compared to two PA servers working in concert.
Other desktop alternatives do exist, of course. There's Jack, designed to provide low-latency, realtime audio rendering, but these days it seems it too seems to operate best, and is most often configured to do so by default, in conjunction with a PA daemon. And MPD of course, which I confess I have much interest in, but very little other incentive otherwise to actually try for myself. I don't actually known what it's capable of. Perhaps you do? I wonder, is it just, as is eponymously implied, a music player daemon? Or can it actually be extended to do the kinds of things I've come to expect of PA as hinted at above? I really should find out.
Anyway, if you haven't had a look at this, it might interest you: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
The author takes care to provide many impressive benchmarking results as proof of the worth of his efforts. If that sparks your interest, you'll find the Android port homepage here: http://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Android/.
And try to remember that PulseAudio is a more mature and proven project than is Android itself, much less SoundFlinger, and each of these three could be said to have experienced some rather rocky starts.
As for the Bluez project being recently dropped from Android and its even more recent Android-focused development, I believe these things are likely just as related as they appear to be. I would have to dig deeper than scanning a few kernel changelogs to be sure, but as I understand it for about a year or two, Bluez has been undergoing a codebase overhaul. I expect that in such a scenario the Linux kernel's default Bluetooth stack would have to focus initial efforts on the Linux kernel's core x86 support, and especially providing ARM support would prove difficult due to its lack of a default firmware interface and handling the myriad hardware access mechanisms might just have been too much at the time. Again, these are my assumptions, but what has definitely happened recently is a concerted effort at full Android support. If my assumptions are correct, then probably the Bluez project just got caught up is all. In any case, the functionality Bluez provides, especially where networking transparency is concerned, is definitely superior. Find out for yourself if you'd like to know.
Surely I'll find out for myself soon, as I guess i'll be diving in after all. Never built Android from source before, which doesn't make much sense as I've had nothing but Android devices since my G1, every one of which, up to and including the Dream, was rooted and flashed with at least a replacement recovery pretty much on day one. I guess better late than never, though.
Back soon, I expect! Best wishes!
-Mike
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
*edit of this mistakenly resulted in double-post below*
Entropy512 said:
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
Click to expand...
Click to collapse
Maybe that's true, but if you asked me I'd probably lean the other way and say instead that Ubuntu is in too many places. Honestly, PA is really not complicated if you consider it a suite of core sound apps as opposed to a single, cohesive application. Probably my biggest gripe with Ubuntu's interfaces is that they often do the opposite, which is of course contrary to Unix principles, and in the process they tend to sort of opaque over simple and accessible modular designs.
I won't attempt to argue that PulseAudio is simple by design, as we both know I'd be certain to lose that argument, but it does offer a few lesser known interfaces you might find interesting. For instance, one of my favorite little tools is pacat. This does exactly what it sounds like; point it at one or more of PA's sources and it will concatenate their raw audio output into stdout at which point you are free to pipeline it as you would any other stream. Imagine you took pacat, perhaps also lz4, nc, and another little pipe-friendly PA tool called paplay directed at a PA sync on its system rather than a source, and combined them all into a pipeline. I hope in this you might begin to see some of PA's merits that perhaps you've missed before.
Also, there is pacmd, which is not nearly as straightforward as those others I've mentioned, but is far more capable and very well documented. It can do anything PA can do, really, and is fully scriptable.
I don't know which versions of Ubuntu you use, but those not on rolling releases may not yet have caught up to the PA update that implemented a PulseAudio-module-specific udev adaptation. Newer PA versions now pretty much auto-configure audio modules in the same way early user-space handles kernel-module loading. It's kinda cool, and almost an entirely hands-off process.
Anyway, I'm through proselytizing. I just thought I'd mention these things because they're the bits that I use when I want to do something with it.
EDIT:
Entropy512 said:
...because of my experiences with it, I will never personally put any effort into putting it into more places...
Click to expand...
Click to collapse
I looked again and noticed this. While I fully understand where you're coming from here, I thought I heard some French kid on YouTube say that this was not the sort of response that should be expected for OmniRom feature requests. He described a sort of democratically driven road map, and specifically he said that if a feature request was well enough supported by the users, then the developers would implement it even if they did not agree it should be done. Has this policy changed?
Of course I realize that youtube guy was probably talking about majority rule as opposed to a well-argued request, and that I'm only one person, but above you say you will never do this thing, without making any allowances for the possibility of a vote or poll or similar.
Like I say, I fully understand your position on this, as I, of course, do not intend to devote my own efforts to something like further Android fragmentation for instance, vote or no vote. I just wish to know what to expect here, and if maybe I missed something.
-Mike
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients - All apps would have to be presented with something that is "audioflinger-like" which didn't offer the extra features offered to clients. Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Entropy512 said:
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Click to expand...
Click to collapse
Wow, man! Thanks very much indeed for replying with honesty and humility. I'm very pleased that I didn't, or at least I hope I did not. Even if you had said otherwise I would have fully understood, of course, but as it is, I'm also very impressed. I like discussion. Thanks, man.
Two questions: what's yamahell? And, because you say you've worked with it, can you tell me about AudioFlinger or whatever it is and maybe why the status quo is desirable? I thought it was a problem. I'm asking these things for my own edification and because I think I'm gonna try something to do with a PA replacement.
While I agree PA may be overkill, I really don't believe pulse has to be applied monolithically, you know? It's already designed to work with modules, so maybe a subset would be sufficient. Clients only communicate with libpulse.so for the most part, for example. And for the past few months (on an upstream system) PA and Bz have been working really well together. So I'll try it, maybe, after you tell your horror stories and I can judge for myself.
-Mike
-
Entropy512 said:
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients...
Click to expand...
Click to collapse
I assume you mean the first one, the blog on the initial port? Well, I believe that may have changed since then. The actual port homepage at freedesktop.org (the second link I provided) says this:
Code:
...[T]ested on Samsung/Google Galaxy Nexus as ... reference implementation... [P]ort fairly straight-forward for ... devices with ALSA support.
Various bits of functionality are available, and this is a moving target. The following are tested at the time of writing this section:
Audio playback for most apps using native Android APIs
Volume control
Switching of outputs depending on the device plugged in (headphones, headset)
To Be Done
The following pieces are either partially or not at all implemented
Audio playback API completeness: infrequently-used bits of the API (loops, markers, etc.) are not implemented
***BIG ONE*** Calls: this is work-in-progress, but needs to be cleaned and merged
Policy: initial implementations of volumes and port switching are done. There are probably a lot of bits of policy that still need to be implemented for us to have feature/bug-parity with standard Android.
Audio record API: can be implemented fairly easily like the playback API was
***NOT CLEAR ON THIS*** Audio effects API (we don't support this in PulseAudio at the moment)
Entropy512 said:
Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
Click to expand...
Click to collapse
Something tells me this is a statement I should be able to fully comprehend before getting neck deep...
Entropy512 said:
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Click to expand...
Click to collapse
It doesn't look so huge to me, as much is already done, I think. But then I've to hear your horror stories so I will reserve judgement.
Entropy512 said:
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Click to expand...
Click to collapse
Yes, that article was written then, but the freedesktop.org homepage was created March of this year. I suspect some changes have accumulated along the way, and because PA is an actively developed high-profile application hosted and backed by RedHat, I expect that website landing page would be removed soon after it became irrelevant. I will, of course, reach out to the maintainers at that end as well for advice.
But... that's kind of the point... less redundancy, you know? Less fragmentation? No need for separate groups for thisnkind of stuff. I just thought that was inline with omni ideals. Is there another way that you know of that could as easily bring a like convergence of functionality with other Linux systems? I just wanted to effect something along those lines and I thought omni sounded like a place worth starting.
Also, I want those things.
-Mike
P.S. This is the git repo described in the .XML repo definition for the PA build-code at freedesktop.org: http://cgit.collabora.com/git/
You can see the android specific PA packages are being worked on, and very recently. Also, ALSA is seeing somewhat recent dev work as well.
EDIT: This may not even be quite as difficult as i initially assumed.You can also see at the following git repo that a commit was made to master referencing 'mako' 5 weeks ago.
http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/
yamahell - the hell that was working with the Yamaha MC1N2 codec seen on many Galaxy S2 family devices.
Poorly documented, kernel code written by a member of a primitive tribe with no concept of zero, Samsung's blob HALs doing all sorts of unpredictable crap requiring workaorunds and hacks...
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Entropy512 said:
...no concept of zero...
Click to expand...
Click to collapse
....should I?
Entropy512 said:
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Click to expand...
Click to collapse
This makes very good sense. While I think the PA 4.0 changeligs from July or so may acknowledge this lack they also seem to indicate it's been addressed. Would you mind looking? Not positive I'm reading it right.
-Mike