Hey guys,
Recently I have been seeing companies releasing devices for Android that are not phones e.g.
Android USB Sticks:
techland.time.com/2012/05/18/pc-in-your-pocket-74-android-stick-goes-on-sale/
or more recently a game console:
kickstarter.com/projects/ouya/ouya-a-new-kind-of-video-game-console
I'm in University now studying Electrical Engineering and I've had an interest in electronics since I was young, so now I thought it was possible for me to design my own device. But so far my only luck with getting anywhere was drafting designs of the device and finding development boards online. Sure i could start off with development boards to test software (which i'm planning to do) but I am quite lost as to where I should go next. For example where to I get a manufacturer to produce my device or where to purchase a processor/motherboard that is custom designed for my project.
It would be really great if someone could point me in the right direction,
Scott
that's an ambitious project, I've just finished 2 degrees in EE and in the long term i'm looking to do similiar projects, but right now it is beyond my capabilities. But what i have done is buy a very cheap dev kit from STmicroelectronics with their ARM m4 chip onboard. (STM32F4)
this chip should be powerful enough to get started on and all the pins are broken out, plus the device includes a programmer and is powered over usb.
It was less than €20 but is still sat in its box as I've a lot to learn before cracking it open.
Have you any experience with RTOS for ARM, Keil offer a free trial version of their well respected uVision MDK software, it supports the above board directly and removes the need to configure a tool chain etc. Personally i'm trying to get eclipse on ubuntu to program it bit Keil uVision will allow me to blink LED's etc so long as my program is under 4Kb.
I too am only starting down this project but i hope the little i know has been of some help.
As for custom devices, well thats a whole other ball game, you will need to make out a schematic, then a board layout, then gerber files. After that you need a small run on a pick and place / reflow line. It's very rare these work out first time round, attention has to be paid to details like noise sinking, pull up resistors, matching logic levels and optically isolating external devices etc.
It's great that you are looking beyond your course material, I've learned much more from personal geekery rather than just taking notes from a lecturer. Anything you do outside the course will benefit you in a better degree at the end.
I've never been designing device from scratch, and I'm also just first grade student. Anyway I could imagine how this might look for small company or single person:
1) Decide what do you want to build-up. Easiest todo is custom dev-board, it can be always redesigned and packed into tablet case. The hardest to-do is mobile phone, and it's nearly impossible to create such thing due to high level of embedding everything, and need to sign pretty serious agreements with RF CPU (and other things like transceivers, antennas, duplexers) supplier like Infineon or Qualcomm.
2) Think what main components you'll need, like LPDDR, SoC (CPU), PMIC (SoC manufacturer usually recommend PMICs to be used and provide reference board schemas for using both), battery fuel gauge, charging controller (both might be built into PMIC, depends on model), screen+touchscreen (there are dozens of such, one might want to decide its size already, but in case of dev-board like build it usually can be replaced by some smaller/bigger with small HW modifications or without modifications at all), sensors like gyro, compass, pressure, light, whatever.
3) Search through suppliers websites and decide what models of ICs you want to use (I'd pick only open hardware), order engineering samples and get reference schemas, rather start from SoC(OMAP4460 for eg.)+PMIC pair, then decide about the rest.
4) Don't forget about extension slots like USB ports, DC supply, serial converters, whatsoever.
5) Start designing PCB board. IMO it's impossible for begginer to project any usable PCB for embedded system, I'm begginer and I'm failing with simplest boost HF DC/DC converters (like 10-20 parts on board), while such board would have thousands of elements on it, and multi layer board to fit it everything in some rational size.
6) Find company that will make prototype for you - they should make board + solder all the components you provide them - one with no professional (and very, very expensive) soldering stations is not able to solder BGA components at home.
7) Test it out.
Relatively, assuming that main components are free engineering samples, this might be not so money-expensive way to create some useful stuff. But for sure it's very, very time expensive, and begginer alone will nearly for sure fail.
//edit:
I just re-read my post and figured it might be pretty demotivating. I'm not saying it's impossible, but I'd suggest you to start from something easier - ARM dev board is the thing you need. As Quiggers stated above.
Just noticed these - cheap and powerful dev boards:
http://wiki.xbmc.org/index.php?title=Allwinner_A10#Other
Custom design
I'm looking to do the same, has this worked for you? I'm looking to build a custom android based mobile device as the original poster. I haven't had any look finding the correct electrical or device engineer to provide me any assistance. Are you available to assist?
Quiggers said:
that's an ambitious project, I've just finished 2 degrees in EE and in the long term i'm looking to do similiar projects, but right now it is beyond my capabilities. But what i have done is buy a very cheap dev kit from STmicroelectronics with their ARM m4 chip onboard. (STM32F4)
this chip should be powerful enough to get started on and all the pins are broken out, plus the device includes a programmer and is powered over usb.
It was less than €20 but is still sat in its box as I've a lot to learn before cracking it open.
Have you any experience with RTOS for ARM, Keil offer a free trial version of their well respected uVision MDK software, it supports the above board directly and removes the need to configure a tool chain etc. Personally i'm trying to get eclipse on ubuntu to program it bit Keil uVision will allow me to blink LED's etc so long as my program is under 4Kb.
I too am only starting down this project but i hope the little i know has been of some help.
As for custom devices, well thats a whole other ball game, you will need to make out a schematic, then a board layout, then gerber files. After that you need a small run on a pick and place / reflow line. It's very rare these work out first time round, attention has to be paid to details like noise sinking, pull up resistors, matching logic levels and optically isolating external devices etc.
It's great that you are looking beyond your course material, I've learned much more from personal geekery rather than just taking notes from a lecturer. Anything you do outside the course will benefit you in a better degree at the end.
Click to expand...
Click to collapse
Technexion
I have used OMAP3530 CPU. The TAO3530 is a good starting point and you can get a Tsunami board.
s8500 board with tablet touchscreen
hi dudes,
i have an old wave s8500 but the screen is broken. and i have an old tablet screen 7" from herotab8/dropad8.
can i use the tablet screen with the s8500 board? is not drivers necessary for the touchscreen? and where will i get the drivers?
and do i not need the datasheets of the pins to connect?
)
What we REALLY need is for someone to make a SoC that's basically like the one in the Raspberry Pi, but substitutes a FPGA for the GPU that's big enough to re-implement GPU functionality... long after the chip has left the fab & gotten soldered onto an open-ended generic ARM stick with no specific purpose, and thus manages to officially avoid getting infected by DRM-mandated licensing terms (ie, anything *officially* licensed to support h.264 or HDMI) that keep making totally open drivers nearly impossible. After all, if the drivers were 100% open source, there's no way they can stop you from commenting out the part responsible for implementing Cinavia, or lying to endpoint devices (like your home theater amp) about HDCP compliance
To deflect infringement claims, a company that made Android boards from the FPGA-equipped SoCs could make it with a soldered-on DVI port instead of HDMI (HDMI connectors are encumbered by viral licensing, DVI isn't), and put a reference design on their website for a wacky octopus cable that used the DVI-A pins to output unbuffered 3-bit pseudo-VGA, and used the remaining pins as a high-density breakout connector for a bunch of half-duplex RS-485 ports and GPIO lines that just *happened* to use DVI/HDMI logic levels
Of course, you'd never be able to legally sell a product based upon that board to end users in the US with the taboo technologies supported "out of the box", but other companies outside the US not subject to our self-inflicted wackiness could, and hopefully WOULD, buy enough of those boards to drive the price down enough to make them cheap for American hobbyists to buy on eBay and use for our own guerrilla Android-powered hardware projects.
In theory, the Xilinx Zynq 7000 series sort of does this... but at the moment, they're so ungodly expensive, you could almost buy a half-dozen Nexus 7 tablets for the price of their Android-capable dev board.
sounds great dude
Nice
Nice post
Hardware for Android D
Its not even turning on now...guess i will have to take it to a computer shop now, are you sure it has to be major things like "dead hard drive to a burned up chip to a bad motherboard."?
I'm just looking to be pointed in the right general direction here.
How would I go about hooking up an LCD and touch panel to an Android board (Raspberry PI or something similar). This is for an embedded device.
Something like a Hannstar HSD062IDW1
sbarrow said:
I'm just looking to be pointed in the right general direction here.
How would I go about hooking up an LCD and touch panel to an Android board (Raspberry PI or something similar). This is for an embedded device.
Something like a Hannstar HSD062IDW1
Click to expand...
Click to collapse
Hey, most of these ARM dev boards have raw LCD headers. If you're an electronics designer then you can go design a PCB to do things like level shift those bits and maybe convert those parallel signals to something else (LVDS or HDMI or watever). But from what I understand, you already have a video out in the form of HDMI and svideo. Some of us here at ArcDatum have done embedded systems research on a whole bunch of ARM boards (BeagleBoard, Pandaboard, the obscure ODROID-X) and almost all of them should have LCD headers. As for touch screens, that's more difficult. Chances are you'll have to use GPIOs or find a screen with HDMI input and USB output for touch sensing. Otherwise you'll have to design an touch screen input/output driver (which actually isn't that hard once you know how.....finding out how is the difficult part since so many of the chips they use have little or no documentation).
You might be in luck with iPhone screens. I personally have heard rumors of people reverse engineering the screen signals and driving them.
Edit: So i looked at your Hannstar link. Looks like you have a 10.5V LED backlight. So u'll have to drive that separately; that's easy enough. As for the actual signals. Looks like the pinouts you have all the RGB 8bit per color channels as well as your power stuff, ground stuff, and your clock inputs all of which can come from either your LCD header on ur RPi (if it has one; i know the BeagleBoard-XM has them) or an external power supply (for Vcc etc). Note you should tie all grounds together in many cases. As for the other random signals you will have to figure out if they're necessary to connect to something (Even if it's ground) or if you can leave them floating. Watch out for your voltage levels and how much current the RGB signals on the display will sink. Likely case is you have to do a level shift from something like 1.8V logic to 3.3V logic or something like that. When you're picking your IC to do that level shifting, also be very aware that the IC has to be able to change from 0 to 3.3V fast enough. You will have to verify that within one clock cycle, the slew rate of every pin (aka each bit for the RGB channels) is high enough to change from a high value to low or vice versa before the next clock edge comes along. If not you're data will be considered corrupt or just completely invalid.
Edit2: Your title states that you're trying to make this work with Android. I think in fact you are trying to drive the LCD with the System on a Chip on the RPi. Depending on the SoC and kernel, you might have to enable the LCD header pinouts in the kernel. Don't quote me on this though. I could be totally bull****ting you. My GUESS is that the same signals that go to the HDMI chip go to the header and in fact when using the header, you're just pulling the logic of those same signal lines (which also means you have to be extra careful of the current you're sourcing from those lines)
I wish to understand your motivation.
There are plenty of cheap Android tablets available with LCD touch screen. Now instead of trying to use one of these you want to get inferior "WhateverBerry" and engineer LCD interface + software stack etc spending your time and money.
Am I correct describing your intention?
Also I am not sure that Android is a good fit for embedded development which is mostly applied to some type of real-time controllers. It is not real-time OS.
If your want to build quickly an embedded controller with LCD touch you can get it done using Arduino boards. There are few LCD modules with touch capabilities available but with very poor documentation. It will require some work but it is feasible to achieve in a few days. It would cost you about $100 in components including Arduino and LCD shield and software is free.
Good luck!
sbarrow said:
I'm just looking to be pointed in the right general direction here.
How would I go about hooking up an LCD and touch panel to an Android board (Raspberry PI or something similar). This is for an embedded device.
Something like a Hannstar HSD062IDW1
Click to expand...
Click to collapse
Adapt0r said:
I wish to understand your motivation.
There are plenty of cheap Android tablets available with LCD touch screen. Now instead of trying to use one of these you want to get inferior "WhateverBerry" and engineer LCD interface + software stack etc spending your time and money.
Am I correct describing your intention?
Also I am not sure that Android is a good fit for embedded development which is mostly applied to some type of real-time controllers. It is not real-time OS.
If your want to build quickly an embedded controller with LCD touch you can get it done using Arduino boards. There are few LCD modules with touch capabilities available but with very poor documentation. It will require some work but it is feasible to achieve in a few days. It would cost you about $100 in components including Arduino and LCD shield and software is free.
Good luck!
Click to expand...
Click to collapse
I agree with this, for the most part. Although theres no reason his application wouldnt be better with Android. What if theyre making some sort of consumer friendly appliance. Android wud be a great place to start. Arduinos wud be good for tiny applications but if they want anything pretty it wont have enough horse power.
Also Im not sure how RTOS fits into this. Sure Android isnt an RTOS, but ur phone is Android and thats an embedded system too. Just because it isnt deterministic doesnt mean it isnt suited for embedded. Just go look at basically any of the Texas Instruments ARM based android/linux dev boards.
Anyway back to the topic at hand. If you want a high powered device then try a BeagleBoard with a third party LCD attachment. It wont be cheap, you would basically have an android tablet only itd be for development (and I mean product development, not just software development). But if you dont need 700+mghz of 32 bit addressing lol, then yes go with a much cheaper arduino and lcd.
Edit: Look at this, I think you'll like it (its an all in one ARM development board):
e2e.ti.com/group/universityprogram/educators/w/wiki/2252.am335x-starter-kit.aspx?sp_rid_pod4=MTk2NzAwNDYzODgS1&sp_mid_pod4=40798754
Also I should clarify Arduinos are a 'cheaper' solution, not a 'cheap' solution. Arduinos are not cheap for the amount of processing power u get and they are almost never suited for LCD applications (but there are a few).
Sent from my SGH-I747M using xda app-developers app
I am glad to have this discussion, it helps to clarify choices we make and avoid waste of time.
RTOS is needed if high rate data acquisition is the core application. If time uncertainty of Android apps execution is tolerable then it might be a good choice considering great UI and communication capabilities.
A number of projects utilize commercial Android hardware with external Bluetooth or USB accessory/ host. In this configuration external accessory acquires and stores data in a buffer, Android terminal reads this data buffer and then does data processing and visualization if necessary.
This combination looks the most efficient since it provides great flexibility with minimal resources.
Low price of Raspberry PI and good marketing attracted a lot of people but usability of this board is very limited. You get what you paid for. It is underpowered for modern Linux and Android, does not have ADC, not suitable for low power (battery) applications. Originally, its main purpose was declared to make learning of programming languages more accessible.
Cheers!
screen
hello Folks,
i even have a broken tablet, but the touchscreen is still ok.
and i still have a samsung wave s8500 with broken screen but it still running.
is there any solution how i can connect the 7 inch screen with the wave?
the 7 inch screen is a mid tablet dropad/haipad.
is there any link to hardware manuall..
and where can i get the driver of the mid?
thanks in advance
Samsung Galaxy Tab 2 7" to LCD
is ther anyone trying connect samsung galaxy tab 2 7" to LCD
or it is imposible.... (
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