[DDDamian]

I read on a a post on a Ubuntu forum somewhere that was describing the same problem, the post didn't state what media software they were using however their solution was to upgrade the kernal to 3.6.

So I tried this and it worked, I now have audio on wake.

Would be funny if that's all it is - it caused a little angst amongst the team, blocked Frodo release and isn't really fixed....

[Martijn]

iirc OE is on kernel 3.7 and still not working (neither was it on 3.6)

[fritsch]

@DDDamian:

I am debugging this since several hours now: The problem is rather simple. The device "used" by AudioEngine before the suspend is not working afterwards. I simple m_sink->Deinitialize() within Factory:uspend(); is enough to get it working again. One can combine this with recalling EnumerateEx and also get device that are "newly" plugged in after resume.

I made a PR where we are currently discussing the Suspend / Resume part - and Martijn is the honored beta tester :-)

[Martijn]

I feel more like an abused gpig ™

[Memphiz]

@fritsch is there no callback from the os you can utilise whenever the devicelist changes? This would be better then "polling" imo

[fritsch]

@Memphiz:
For the start I used this polling method, as we want to have xbmc first up, when there is a audio - as AE cannot add others after that has happened. EnumerateSinks was called only once - at start.

Later i had the idea to expand it for suspend / resume and it was not that easy to test, cause my machine with 3.7 kernel don't have a problem on resume. So again a dedicated point, where one should scan for new devices.

For the long term I don't want that polling as it just sucks - it could be done in general with udev, so we can register and get events when something snd relating changes. I don't known AE not good enough to make a good proposal on where in the code it should live.

WIP here: https://github.com/xbmc/xbmc/pull/2152 Any input welcome.

[fritsch]

@Memphiz:
Nice! you are exactly doing this within https://github.com/xbmc/xbmc/commit/6c00...3f9a501171 - that is cool :-)

[dave-]

Would be funny if that's all it is - it caused a little angst amongst the team, blocked Frodo release and isn't really fixed....

IMO this has nothing to do with XBMC. As per my previous post:

I had noticed no audio via HDMI on resume from suspend recently and google landed me here. My Asrock ION330 on first resume (after being suspended for 24hrs etc) had no audio. My wake script loads mythtv-frontend first, I switch to XBMC as required. Audio doesn't work on either which makes me think its not application related.

Did some more checking. On the first wake there is no sound device registered by my receiver. If I suspend and resume immediately, the sound device starts to work but nothing in the aplay output changes.

Code:

[root@modena ~]# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.25.

[root@modena ~]# uname -a
Linux modena 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux

[root@modena ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 0: VT1708S Analog [VT1708S Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 1: VT1708S Digital [VT1708S Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

I have since found that without doing the 2nd suspend/wake, I can get audio to work again by restarting my desktop. That is, I use SLiM as my desktop manager and if I restart that daemon. When the desktop starts up again (XFCE), and it fires up mythtv, audio is working again. If I make XBMC my default launched app on startup, same thing.

I'm not really sure what to change or try out as it is beyond my knowledge. All I know is that it didn't always happen so I can only assume it was after a system upgrade that touched the kernel, pm-utils, alsa or who knows what. But definitely was not XBMC as v11 (current for me) was ok at one point and v10 before that.

[fritsch]

@dave-

We have to differ here. Same have no sound after resume, but it get it back when they play a passthrough track. For these users I want to fix Audio. You describe a similar workaround "When desktop starts up again" everything is fine. This behaviour my patch implements.

And second: It waits for devices at startup, by "reinitializing" the global alsa sink tree (tree where all devices are in).

So if you can, give it a try. See the PR.

For the longterm I want to use the very same system to implement "hotplug detection".
Get Event:
if add -> add -> add to m_sinkList by partially enumerating
if remove -> stop all Audio -> clear all sinks -> reinit complete soundsystem -> reloadSettings

That is the main idea.

[tlund]

Is there an OpenELEC build somwhere where these changes are included?

[fritsch]

Yes, try this one: https://github.com/xbmc/xbmc/pull/2218#i...t-13367315

[xvlun]

i was wrong.

[fritsch]

@xvlun: No problem. I am working with sraue in the OpenELEC team, so we made this build yesterday.

[xvlun]

ok, i compiled the master branch (cloned yesterday morning, ION x64) on my own yesterday and found that quite a few bugs disappeared (e.g. sound after suspend, xmbc not freeing the audio device if nothing is played (breaking xsqueeze) and also a strange bug that caused having no sound after pausing/resuming playback). All in All OE works a lot better than last week...

[fritsch]

@xvlun:
Which new bugs did you find? Cause i have a new PR in the queue that fixes some other stuff and improves some things.