[stupid-boy]

many people, including me, live with hope that some day they will be able to use their USB soundcards with XBMC on their raspberry pi's. that is why i (re)started this initiative.

WARNING for deliveries: this code is at EXPERIMENTAL stage, do not include it in any way in your releases! there are a lot of problems with it!

so, work is based on Bellagio OMX implementation. i made a lot to make it compatible with Broadcom components and to get it working in tunneled mode. doing that i try to keep original hierarchy untouched.

current status:
ALSA component is hardcode attached in place of HDMI render. it uses only 'default' ALSA device and support only 2 channel PCM. NO PASSTHRU!!!
i must clearly state that i will not be able to accomplish this without incredible help from popcornmix. tank you man for your instant support and endless patience!

testing it on my TV via HDMI ( thru ALSA of course ), it works. as i do not have nonstop access to my TV ( wife problem here ), i can't test it in deep, but very basic tests are passed. i expect that there must be some delay between video and audio! however last time i tested it, i seek forward and didn't notice any delay, which surprised me.

what is pending, and for what i need help:
1. test using real (USB) soundcard. as above, i have limited access to TV/receiver for tests.
[FIXED] 2. playback finish takes longer than i expect. will take a look at this at some point later.
3. if i select passthru, it hangs during tunnel establishment at end of or after buffer exchange phase. again, i will take a look later.
[FIXED] 4. delay between video and audio. as i do not talk ALSA language, someone that knows it must help. othervice i am lost here. i tried some shots in the dark, of course failed as i expected.
5. passthru may require help from similar guy, that know how to speak with ALSA.
6. may be many more, but let stop here for now.
for any 'will take a look', any ideas or help are very welcome. for any other or not in list, too.

to build it you must configure WITHOUT --disable-alsa switch! do not ask me for other details on how to build, i expect only knowledged people to try this!
preferably start it from SSH. it will flood stderr with traces. actually they are the only logs from this component at the moment.
if you wish, feel free to use it as base for 'pulse' component. i know that is long time dream for Raspbmc. if you do, do not remember to add it to this companion.
do not ask here how to configure your default alsa device. google will help perfectly on this.

finally, link to code: https://github.com/stupid-boy/xbmc/commits/OMX_ALSA

and not at least: be good boy, "DO NOT KILL THE PIANIST, that is all he can"

[stupid-boy]

fixed 4. delay between video and audio.

[stupid-boy]

fixed 2. playback finish takes longer than i expect

-----------
come on guys, no one interested from this?

[dhead]

come on guys, no one interested from this?

I'm not a developer but this is a great news, can't wait to test it.

What I like to know is:
1. How this affect the cpu load ?
2. Did you also enabled AE ?
3. Do you believe it will be more usable in regards to performance to users that need quality stereo output and not for analog surround (like Creative X-Fi 5.1 USB) ?
4. Do you use the fiq_split firmware ?
5. Is this means the current dual audio patch will be unusable with analog usb output and onboard hdmi ?, so maybe the solution is to set such setup with pulseaudio ?
6. Is this also making i2s devices a viable option for XBMC ?

[stupid-boy]

don't have answers to all, but:

1: from yesterday test: 7.3G mpg file, FullHD with AC3 5+1, from smb share -> CPU was around 75%. do not know CPU clock, as i use ondemand overclock.
2. NO. this is component, that connects to internal manner of working inside OMXPlayer and outputs using ALSA, not videocore. full AE can be enabled in order to use its helpers to determine ALSA devices and also to produce GUI sounds, but not as main output. not tested for now.
3. not sure i know what Creative X-Fi 5.1 is. intent is to enable standard for RPi passthought. if it will benefit from passthrought, then, yes. personally i have turtlebeach with optical output, i plan to use it for 5.1 passthroughts. may be that creative will use the same approach.
4. not sure. my current version is 3.6.11+ #541 PREEMPT Sat Sep 7 19:46:21 BST 2013 from rpi-update.
5. not exactly. idea is to add another option in settings, keeping current ones. while it seem possible to made any combination between them, i do not plan it for now. at first time i prefer to keep changes to existing code minimal. yes, it may will be possible, but not at first stage. remember, Broadcom components are better tested, better use them where possible.
6. any device that have ALSA driver can be used with this code.

[dhead]

Thanks stupid-boy.

This sounds really good.

[stupid-boy]

ok, now i have one good and one bad news.
first, good: i was able to do initial dolby digital passtrough using my turtlebeach via optical.
sadly that is all about good news. bad news are that for now i must use hard coded device and other related stuffs inside my component. i don't know how to accomplish this outside code. what i need is some way to assign say iec958 to default ( or other name, but universal ) without loosing its @args. easiest and most universal way seem to be in asound.conf. please, really i need help for this. i am not ALSA ( and linux at all ) guy. all places where i ask till now, leaved me without answer.
other way will require inclusion of AudioEngine and a lot of changes in current code. i prefer to deal without this overload.

[FernetMenta]

Have you seen this? https://github.com/xbmc/xbmc/pull/3356
Plug the ALSA sink into PRi AE and it will make your life easier.

[stupid-boy]

switching to real usb card changer everything. with HDMI above fixes worked, but not any more. synchronization between audio and video is totally broken, as ALSA begun to return completely different and non deterministic results i use for this synchronization. may be because of these results, play stop is broken. also ALSA starts playback at some different points.
in short, i am back to beginning.

another difference i spot: HDMI needs AES0 bit for passtrough to be set, turtlebeach+receiver does not.
for now i do not see how reliably to determine delay at ALSA level. this prevent me from A/V synchronization.

FernetMenta, AE sink is one of main sources where i look. most likely i will end up integrating it completely. examples why i can't currently:
snd_pcm_delay and snd_pcm_status_get_delay returns incorrect things for USB. both work ok for HDMI.
snd_pcm_avail and snd_pcm_status_get_avail too. only snd_pcm_status_get_avail work on HDMI, but not for USB.
these are used in AE sink and are expected to work.

[stupid-boy]

well, i fixed buffers and delays.now i am back to (nearly) perfect synchronized audio and video. ALSA runs smoothly without underruns.

however, there are glitches in audio. a lot of them. i can suspect they are in USB stack. on my side everything goes thru USB, including input, as my sources are located at smb on another machine ( we know, on RPI network is connected as USB device too ), so it is massively flooded. i tried with nrpacks=1 and nrpacks=20, no difference. i even tried nice -16 and result was: WOW, what unseen response!!! but glitches are still here with no change. only option, that made any difference, was rarely discussed async_unlink option. it eliminate part of them, but not all.

i am not in position to continue investigations. i do not and don't want to know how to fix/rebuild kernel. i do not know if this is software or hardware USB limitation, and don't care.

intent of this project was to be used for learning and also as 'proof of concept'. it does them both. i learned something and it proved that: 1. it is doable and can work; and 2. currently RPi is not suitable target for such things.

my final decision: i will stop this project. in next few days i will find some time to cleanup current code and to push it to git, but for now i will discontinue additional development. may be i will try it again after some time with hope USB stack is fixed. may be i will buy some i2s -> spdif device, if any exist, and will try with it. or may be someone else will try all this mess. who knows, but for sure for now i have to stop.

[popcornmix]

See https://github.com/raspberrypi/linux/issues/351

dwc_otg.fiq_split_enable=0 may help.

It is something that is being worked on.

You may find a different USB sound card behaves better, and lowering the bit depth/sample rate so multiple USB packets per frame are not required helps.
Note, you can get the GPU to resample the audio to a lower rate for testing (by setting sample rate of audio_mixer to a lower value). Possibly 32kHz or 44.1kHz would be okay.

[stupid-boy]

It is something that is being worked on.

you know, i am not in touch with latest additions. usually i do not understand what commit description mean. i am not linux gui, so that terminology usually does not help me. as i already state, may be i will get back to some tests later.

You may find a different USB sound card behaves better, and lowering the bit depth/sample rate so multiple USB packets per frame are not required helps.
Note, you can get the GPU to resample the audio to a lower rate for testing (by setting sample rate of audio_mixer to a lower value). Possibly 32kHz or 44.1kHz would be okay.

first, i have only that card. i asked if some else can try this code, no candidates so far. i will leave that code in github, so everyone will be able to test it with its own card and if it work, to use it.
next, lowering parameters as not an option. all or nothing. also i tried with some 44.1 mp3, result was the same. 32 and lower will be big compromise i am not ready to made.
also what i didn't but must, i didn't try to connect turtlebeach directly to RPI. this can be root of the problem, as it is connected thru some chinese hub now ( actually this hub serves everything here ).
and also, as per commit i show to you recently, my turtlebeach is not FULLY supported yet. i don't thing this commit will solve problems, but it clearly shows that that card is not perfectly supported.

[popcornmix]

Try "dwc_otg.fiq_split_enable=0" added to cmdline.txt. It may just fix your problem.

(reducing sample rate was just a temporary suggestion until issue 351 is resolved).

[stupid-boy]

tried, does not help
did update, as my firmware was relatively old, no difference
also moved my turtlebeach directly on rpi, no difference

[dhead]

Just thought it worth to mention that it looks like it getting easier for novice user to add i2s devices and there is at least one low cost daughter board implementation.
You still need to have you're soldering iron nearby but only for soldering headers to the P5 on the Raspberry Pi.

The relation to this thread is that it worth testing the omx alsa implementation with i2s device as it seems the RPi still got some issues with usb.

I don't see myself trying this (i2s and stupid-boy's omx alsa) in the near future as I've got other projects in mind, anyone that do tries please post about it.

See
https://github.com/raspberrypi/linux/pull/444
http://www.hifiberry.com/ (also watch the how to video)

Edit: I forgot to mention that these external i2s dacs are stereo only.