AudioEngine branch - DO NOT REQUEST BINARY BUILDS

gnif:

My previous passthrough issues are resolved. AirPlay will still lock XBMC, however. If you don't have iTunes installed/don't wish to install iTunes let me know and I'll start digging into the code (which I've been meaning to do for weeks but...). I just feel this may need resolved before a master merge since AirPlay was one of Eden's touted new features.

Full Log:
http://pastebin.com/XzkQAsJp

i think i have a fix for this ready in some mins... yep - PR send to gnif...

All the heavery-hitters are starting to weigh in

Glad you guys are helping out.

(2012-04-14 02:19)Memphiz Wrote:  i think i have a fix for this ready in some mins... yep - PR send to gnif...

Works great. Thanks.

(2012-04-13 01:22)gnif Wrote:  @grote002 - this is unrelated to AE, seems like you need to perform a distclean on the source as the configure that has been generated for libblueray is invalid.

I managed to fix it with the install of the latest libbluray

But now when i play a DTS HD MA video (i tried bluray and demos from trailerz.demo-world.eu),the video plays without problem and DTS HD MA shows up on my receiver, but the logo keeps flikkering on/off like it cant find a lock and the audio is silent except for some pop-sounds.

Video of the receiver-screen

While playing the videos nothing shows up in the xbmc.log. All other audio, like Dolby Digital, DTS, and Dolby HD all work fine.

Any idea what could be the problem?

Suspend isnt working either, when i try to suspend it goes back to the login-screen and i have to shutdown the machine remotely

@grote002 - can you please try with the latest updates, your issue may be fixed

gnif, question for you, and I apologize, I don't have logs because while I was fiddling around, it sort of fixed itself...yes, even the backup log is gone. Not sure if it has to do with the enumerating devices code or not.

Let's say my HDMI output was detected as this:
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]

But for some reason changed to this:
card 1: NVidia [HDA NVidia], device 2: HDMI 0 [HDMI 0]

And no, I don't know why it would do that...or if those numbers are even right. But what happened was I built the most recent commit (as of this post...f84a554?) I had no audio. I went into the system -> audio output section and ensured my audio and passthrough was set to HDMI -> HDA NVidia, still nothing. Exited, went back in, and then when I went back to hardware -> audio, there was nothing listed for HDMI Just the onboard HDMI. I could cycle through the options, 2 Intel and one blank. Anyway, I set them both (Audio Output and Passthrough) to blank, exited XBMC, went back in, and sound worked properly.

Anyway, I don't know if an HDMI audio device changing device numbers is something that would come up a lot, or if that would have even been the trouble. If I see it again, I'll ensure to grab a log in a broken and fixed state. Just wondering if the enumerating code is 'smart' enough to pick up a device changing like the above for some reason.

Sorry again, I know that not having a log doesn't give you much to go on...nor is it much of a question. :-)

@fincheresque - Can you please send me your most recent log anyway, the enumerate code is new and we need to be sure its working correctly. As for the dev numbers, they are not what used to be shown in XBMC as the old code was incorrect. The old code used to show the hardware DEV number, not the DEV number that is required to open the device with alsa.

When you run aplay -l (note, lowercase l), you will see that the device numbers here do not match the device numbers when you run aplay -L. XBMC was incorrectly showing the physical device numbers (lowercase l), not the ALSA indexed device numbers (uppercase L).

(2012-04-18 17:11)gnif Wrote:  @grote002 - can you please try with the latest updates, your issue may be fixed

I compiled the latest version yesterday evening and it still has the same problem with the flickering DTS HD MA logo on my receiver.

@grote002 - does TrueHD play? can you please test