[phi2039]

well...I am sorry to hear that this is such an annoying problem. I can certainly understand, since I get annoyed when users post cranky comments while asking for help...

[WJWNL]

well...I am sorry to hear that this is such an annoying problem. I can certainly understand, since I get annoyed when users post cranky comments while asking for help...

Cranky? Is this directed to me? In what way is my comment cranky? I only reposted my problem with a log, that is all... To give you developers as much information as possible.

[phi2039]

Again: I have the same (annoying) problem with the latest SVN build. If I start one movie, the sound is fine, but if I start a second one it says: failed to initialize audio device, check your audio settings.

I'm still looking at the issue. Just try to be considerate of what those reading (and working) may think about what you say.

[WJWNL]

I'm still looking at the issue. Just try to be considerate of what those reading (and working) may think about what you say.

That again was because of the post I have on page 1, it is an identical post, but now with a pastebin like you requested. And it is an annoying bug, if you like it or not, I'm not blaming you for the bug do I?

Just relax, not everyone is against you.

[aaronjb]

The hang actually occurs in the GUI sounds code. You should be able to work around the problem temporarily by disabling them.

This is the sound of me slapping my own forehead - you're right, the issue of being unable to exit XBMC after playing passthrough DTS is down to the GUI sounds. Disabling them nicely fixed that issue and I can once again exit XBMC cleanly.

WJWNL - if that's the issue you're having then the setting is under Configure the System->Configure the Appearance->Navigation Sounds, toggle this to off.


Doing this, however, popped up another issue - which I think is the one WJWNL is having (though I didn't check his log yet).

After playing the first DTS video, attempting to play it a second time pops up the 'Unable to initialize the audio device' message.

Here's a pastebin of the full debug log: http://pastebin.com/f5a611607

The second playback starts at timestamp 00:01:02, and I'm thinking this here is the ultimate breakage (although not necessarily the root cause, of course )

Code:

00:01:02 T:2961584128 M:1482252288   ERROR: CCoreAudioHardware::GetDefaultOutputDevice: Unable to identify default output device. Error = 0x00000000 (    ).

BTW, ignore the massive spewing of ffmpeg errors on the first playback in the logs - that was me hitting the fast forward button (sorry about that, mea culpa :o )


And just for Jonathan - this particular problem (which I realise is completely independent of my thread title, sorry, bugs the wotsit out of me when people do that to me at work so I apologise!) also happens with non-DTS media - second playback b0rks with the 'Unable to initialize..' message.

Pastebin again - this is with 2-channel AC3 audio in an MKV: http://pastebin.com/f43661b43

Second playback attempt starts at 00:11:06


BTW, if I came across as cranky I do apologise - not my intention at all, bugs are a part of life (I've coded plenty myself.. wait.. that's not a thing to boast about is it :o ) - I just want to make sure it's not me doing something boneheaded, and if it isn't, help find the problem and fix it, if possible - if I can do that by providing logs, I will, and if I can find the problem in the code, I'll help out there too

Although me finding anything in the code at gone midnight is looking unlikely, so I'll sign out for the day I think

Thanks muchly!
Aaron

[phi2039]

@WJWNL:
All bugs are annoying. That is the nature of the beast. As a result, there is no benefit in calling them out as such unless you are trying to emphasize the point. I am not concerned about whether or not anyone is against me, nor would make any difference either way. That is irrelevant.

At any rate, your problem is likely occurring when the application changes the nominal samplerate. Manually set the samplerate to 48000 '/Developer/Applications/Audio/HALLab' and run another test. Post a log of the result.

[phi2039]

BTW, if I came across as cranky I do apologise - not my intention at all, bugs are a part of life (I've coded plenty myself.. wait.. that's not a thing to boast about is it :o ) - I just want to make sure it's not me doing something boneheaded, and if it isn't, help find the problem and fix it, if possible - if I can do that by providing logs, I will, and if I can find the problem in the code, I'll help out there too

No complaints at all. I appreciate the very detailed posts.

Unfortunately, I wouldn't exactly call disabling the GUI sounds a fix. It was just an attempt to make life a little easier while we hack at things a bit. Both the previous and current problem boil down to timing/sync issues within the love triangle that is XBMC-CoreAudio-SDL. I have run into both scenarios on my MacMini and had believed them solved, but apparently that was not the case. The good news is that I am more intimately familiar with the surrounding code than anyone could ever want to be, so it should just be a matter of time...

[phi2039]

@aaronjb: Try selecting 'Built-in Output' explicitly in Settings -> System -> Audio Hardware. There is a known bug in the 'Default Output' handling that is likely the cause of your new symptoms. I will likely just remove that code altogether for the time being.

[aaronjb]

Like ships that pass in the night, so to speak, our posts crossed. I realise you were talking to WJWNL but I thought I'd better check it here, too

My Nominal Sample Rate is already set to 48000 according to HALLab, and the device IDs check out with those reported in the first playback attempts in my logs (0x104 is the Built-in Output, and 0x105 the default - and only - Output Stream). The output stream reports as being hooked up via SPDIF with 'Connected: N/A' immediately after the earlier playback attempts, if it has any bearing.


And you're right - disabling GUI sounds is only a workaround, of course, albeit a very good one (I never did care for the clicks myself, anyway )

I have no doubt you'll find the problem given time - and I have no problem waiting, it's not like this is life or death stuff here but if there's anything I can do to help, just say the word.

[edit] Just spotted the post you snuck in there - let me check that setting out, thanks!

[aaronjb]

@phi2039 - Yuppers, you're right - manually setting the option to 'Built-in Output' fixed it right up. I thought I'd done that already, but apparently I was, once again, smoking crack

Thanks!

[edit] To clarify, I didn't know about the bug - I just thought I'd already done that because I remembered playing with that setting.. apparently that was an earlier incarnation of my settings.. or in Plex perhaps.. or on the MacBook not the Mini - too many copies of XBMC and not enough brain cells

[phi2039]

Glad to hear there is an acceptable workaround. I think I will remove the Default code for now to prevent at least that issue. The problem is that when we 'hog' the device for passthrough, it is no longer able to act as the Default Output Device. On systems like mine with more than one device, it simply moves the default to the next device. On a system with only one device, like a stock mini, it operates with no default. One would hope that the default would simply be put back after releasing the device, but one would be mistaken. Unfortunately, this type of thing is par for the course with CoreAudio...

[WJWNL]

Changing the output also solved the problem for me. Thanks!

[phi2039]

Glad to hear. I am also going to poke around at a few other things to see if I can improve the overall robustness of the code. Please post any other issues you encounter.

[jayhawk785]

Built in output is already set in mine, and sadly, I can't change it to correct this problem. That seems to be the default option as it is.

[aaronjb]

Are you seeing it hang-on-exit, or fail to play audio after playing the first video?

And if you could post debug-enabled logs, that would help, too