Conclusion: Sound over HDMI works with the Sapphire Radeon HD 6450 card in my HP N54L microserver. It requires a recent kernel and firmware from Wheezy 7.7 backports and the X.org server. There is no sound without X.org, even if audio has been enabled for the
radeon kernel module. Last year I couldn't get audio over
HDMI to work after I installed a Sapphire Radeon HD 6450 1 GB (
11190-02-20g) card into my
N54L microserver. The cable that connects the HDMI interfaces between the card and the TV monitor supports HDMI 1.3, so audio should have been possible even then. However, I didn't get any audio output by
XBMC playing video or music files. Nothing happened with stock Wheezy 7.1 and X.org/XBMC installed. So I removed the latter two and used the server as stock server without X/desktop and delayed my plans for an
HTPC.Now I tried again after I found some new hints, that made me curious for a second try :) Imagine my joy, when (finally)
speaker-test produced noise on the TV! So here is my configuration and a step-by-step guide to
- enable Sound over HDMI for the Radeon HD 6450
- install a graphical environment
- install XBMC
- automatically start XBMC on boot
The latter two will be covered by a second post. Also note, that there is lot of information out there to achive the above tasks. So this is only about my configuration. Some packages below are marked as
optional. A few are necessary only for the N54L microserver (firmware) and for a few I'm not sure they are necessary at all. Step 1 - Prepare the systemAt this point I don't have any desktop nor any other graphical environment (X.org) installed. First I purged
pulseaudio and related packages completely and only use ALSA:
# apt-get autoremove --purge pulseaudio pulseaudio-utils pulseaudio-module-x11 gstreamer0.10-pulseaudio
# apt-get install alsa-base alsa-utils alsa-oss
Next I installed a recent linux kernel and recent firmware from Wheezy backports:
# apt-get install -t wheezy-backports linux-image-amd64 firmware-linux-free firmware-linux firmware-linux-nonfree firmware-atheros firmware-bnx2 firmware-bnx2x
This put
linux-image-3.16-0.bpo.3-amd64 and recent firmware onto my system. I've chosen to upgrade
linux-image-amd64 instead to pick a special (recent) linux kernel package from Wheezy backports to keep up-to-date with recent kernels from there.Then I enabled the audio output of the kernel
radeon module. Essentially there are at least three ways to do this. I use the one to modify
/etc/modules.d/radeon.conf and set the
audio parameter there. The
hw_i2c parameter is disabled. I read, that it might cause trouble with the audio output here although I never personally experienced it:
options radeon audio=1 hw_i2c=0
JFTR: This is how I boot the N54L by default:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force pcie_aspm=force nmi_watchdog=0"
After rebooting I see this for the Radeon card in question:
# lsmod egrep snd\ radeon\ drm awk ' print $1 ' sort
[..]
drm
drm_kms_helper
i2c_algo_bit
i2c_core
radeon
snd
snd_hda_codec
snd_hda_codec_hdmi
snd_hda_controller
snd_hda_intel
snd_hwdep
snd_pcm
snd_seq
snd_seq_device
snd_timer
soundcore
ttm
[..]
# lspci -k
[..]
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]
Subsystem: PC Partner Limited / Sapphire Technology Device e204
Kernel driver in use: radeon
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6400 Series]
Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 6450 1GB DDR3
Kernel driver in use: snd_hda_intel
[..]
# cat /sys/module/radeon/parameters/audio
1
# cat /sys/module/radeon/parameters/hw_i2c
0
# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 0/1
Subdevice #0: subdevice #0
# aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
pulse
PulseAudio Sound Server
hdmi:CARD=HDMI,DEV=0
HDA ATI HDMI, HDMI 0
HDMI Audio Output
At this point, without having the X.org server installed, I still have no audio output to the connected monitor. Running
alsamixer I only see the
S/PDIF bar for the
HDA ATI HDMI device, showing a value of
00
. I can mute and un-mute this device but not change the value. No need to worry, sound comes with step two. Step 2 - Install a graphical environment (X.org server)Next is to install a graphical environment, basically the X.org server. This is done in Debian by the
desktop task. Unfortunately
tasksel makes use of
APT::Install-Recommends="true" and would install a desktop environment and some more recommended packages. At the moment I don't want this, only X. So basically I installed only the
task-desktop package with dependencies:
# apt-get install task-desktop xfonts-cyrillic
Next is to install a display manager. I've chosen
lightdm:
# apt-get install lightdm accountsservice
Done. Now (re-)start the X server. Simply ...
# service lightdm restart
... should do. And now there is sound, probably due to the X.org Radeon driver. The following command created noise on the two monitor speakers :)
# speaker-test -c2 -D hdmi:0 -t pink
Finally there is sound over HDMI! Step 3 - Install XBMC To be continued ...
I'm changing jobs!
From February 2015, I will be joining Red Hat as a Senior Software Engineer.
I'll be based in Newcastle and working with the Middleware team. I'm going to
be working with virtualisation, containers and Docker in particular. I know a
few of the folks in the Newcastle office already, thanks to their relationship
with the School of Computing Science, and I'm very excited to work with them,
as well as the wider company. It's also going to be great to be contributing
to the free software community as part of my day job.
This October marked my tenth year working for Newcastle University. I've had a
great time, learned a huge amount, and made some great friends. It's going to
be sad to leave, especially the School of Computing Science where I've spent
the last four years, but it's the right time to move on, It's an area that I've
been personally interested in for a long time and I'm very excited to be trying
something new.
A teacher in New York was teaching her class about bullying and gave them the following exercise to perform. She had the children take a piece of paper and told them to crumple it up, stamp on it and really mess it up but do not rip it. Then she had them unfold the paper, smooth it out and look at how scarred and dirty is was. She then told them to tell it they re sorry. Now even though they said they were sorry and tried to fix the paper, she pointed out all the scars they left behind. And that those scars will never go away no matter how hard they tried to fix it. That is what happens when a child bullies another child, they may say they re sorry but the scars are there forever. The looks on the faces of the children in the classroom told her the message hit home.
( Source: 
Earlier today, 
Debian's latest round of angry mailing list threads have been about some
combination of init systems, future direction and project governance.
The details aren't particularly important here, and pretty much everything
worthwhile in favour of or against each position has already been said several
times, but I think this bit is important enough that it bears repeating:
the reason I voted "we didn't need this General Resolution" ahead
of the other options is that I hope we can continue to use our normal
technical and decision-making processes to make Debian 8 the best possible
OS distribution for everyone. That includes people who like systemd,
people who dislike systemd, people who don't care either way and just
want the OS to work, and everyone in between those extremes.
I think that works best when we do things, and least well when a lot
of time and energy get diverted into talking about doing things.
I've been trying to do my small part of the former by
Martin Pitt reported Debian 
Apparently, people care when you, as privileged person (white, male,
long-time Debian Developer) throw in the towel because the amount of
crap thrown your way just becomes too much. I guess that's good, both
because it gives me a soap box for a short while, but also because if
enough people talk about how poisonous the well that Debian is has
become, we can fix it.
This morning, I resigned as a member of the systemd maintainer team.
I then proceeded to leave the relevant IRC channels and announced this
on twitter. The responses I've gotten have been almost all been
heartwarming. People have generally been offering hugs, saying thanks
for the work put into systemd in Debian and so on. I've greatly
appreciated those (and I've been getting those before I resigned too,
so this isn't just a response to that). I feel bad about leaving the
rest of the team, they're a great bunch: competent, caring, funny,
wonderful people. On the other hand, at some point I had to draw a
line and say "no further".
Debian and its various maintainer teams are a bunch of tribes (with
possibly Debian itself being a supertribe). Unlike many other
situations, you can be part of multiple tribes. I'm still a member of
the DSA tribe for instance. Leaving pkg-systemd means leaving one of
my tribes. That hurts. It hurts even more because it feels like a
forced exit rather than because I've lost interest or been distracted
by other shiny things for long enough that you don't really feel like
part of a tribe. That happened with me with debian-installer. It was
my baby for a while (with a then quite small team), then a bunch of
real life thing interfered and other people picked it up and ran with
it and made it greater and more fantastic than before. I kinda lost
touch, and while it's still dear to me, I no longer identify as part
of the debian-boot tribe.
Now, how did I, standing stout and tall, get forced out of my tribe?
I've been a DD for almost 14 years, I should be able to weather any
storm, shouldn't I? It turns out that no, the mountain does get worn
down by the rain. It's not a single hurtful comment here and there.
There's a constant drum about this all being some sort of conspiracy
and there are sometimes flares where people wish people involved in
systemd would be run over by a bus or just accusations of
incompetence.
Our code of conduct says, "assume good faith". If you ever find
yourself not doing that, step back, breathe. See if there's a
reasonable explanation for why somebody is saying something or
behaving in a way that doesn't make sense to you. It might be as
simple as your native tongue being English and their being something
else.
If you do genuinely disagree with somebody (something which is
entirely fine), try not to escalate, even if the stakes are high.
Examples from the last year include talking about this as a war and
talking about "increasingly bitter rear-guard battles". By using and
accepting this terminology, we, as a project, poison ourselves. 
Big changes are always a complicated thing to get done and can be the harder the bigger or more diverse an organization is it is taking place in.
Transparency
Ideally every change is well communicated early and openly.
Leaving people in the dark about what will change and when means people have much less time to feeling comfortable about it or arranging with it mentally.
Especially bad can be extending the change later or or shortening transition periods.
Letting people think they have some time to transition only to force them to rush later will remove any credibility you have and severely reduce their ability to believe you are not crossing them.
Making a new way optional is a great way to create security (see below), but making that obligatory before the change even arrives as optional with them will not make them very willing to embrace change.
Take responsibility
Every transformation means costs.
Even if some change did only improve and did not make anything worse once implemented (the ideal change you will never meet in reality), the deployment of the change still costs:
processes have adapted to it, people have to relearn how to do things, how to detect if something goes wrong, how to fix it, documentation has to be adopted and and and.
Even as the change causes more good than costs in the whole organization (let's hope it does, I hope you wouldn't try to do something if the total benefit is negative), the benefits and thus the benefit to cost ratio will differ for the different parts of your organization or the different people within it.
It's hardly avoidable that for some people there will not be much benefit, much less perceived benefit compared to the costs they have to burden for it.
Those are the people whose good will you want to fight for, not the people you want to fight against.
They have to pay with their labor/resources and thus their good will for your benefit the overall benefit.
This is much easier if you acknowledge that fact.
If you blame them for having the costs, claim their situation does not even exist or even ridicule them for not embracing change you only prepare yourself for frustration.
You might be able to persuade yourself that everyone that is not willing to invest in the change is just acting out of malevolent self-interest.
But you will hardly be able to persuade people that it is evil to not help your cause if you treat them as enemies.
And once you ignored or played down costs that later actually happen, your credibility in being able to see the big picture will simply cease to exist at all for the next change.
Allow different metrics
People have different opinions about priorities, about what is important, about how much something costs and even about what is a problem.
If you want to persuade them, try to take that into account.
If you do not understand why something is a reason, it might be because the given point is stupid. But it might also be that you miss something. And often there is simple a different valuation of what is important, what the costs are and what are problems.
If you want to persuade people, it is worth to try to understand those.
If all you want to do is persuade some leader or some majority then ridiculing their concerns might get you somewhere.
But how do you want to win people over if you do not even appear to understand their problems.
Why should people trust you that their costs will be worth the overall benefits if you tell them the costs that they clearly see do not exist? How credible is referring to the bigger picture if the part of the picture they can see does not match what you say the bigger picture looks like?
Don't get trolled and don't troll
There will always be people that might be unreasonable or even try to provoke you. Don't allow being provoked. Remember that for successful changes you need to win broad support. Feeling personally attacked or feeling presented a large amount of pointless arguments easily results in not bringing proper responses or actually looking at arguments.
If someone is only trolling and purely malevolent, they will tease you best if they bring actual concerns of people in a way you likely degrade your yourself and your point in answering.
Becoming impertinent with the troll is like attacking the annoying little goblin hiding next to the city guards with area damage.
When not being able to persuade people, it is also far to easy to consider them in bad faith and/or attacking them personally. This can only escalate even more. Worst case you frustrate someone in good faith. In most cases you poison the discussion so much that people actually in good faith will no longer contribute the discussion. It might be rewarding short term because after some escalation only obviously unreasonable people will talk against you, but it makes it much harder to find solutions together that could benefit anyone and almost impossible to persuade those that simply left the discussion.
Give security
Last but not least, remember that humans are quite risk-averse. In general they might invest in (even small) chances to win, but go a long way to avoid risks.
Thus an important part of enabling change is to reduce risks, real and perceived ones and give people a feeling of security.
In the end, almost every measure boils down to that:
You give people security by giving them the feeling that the whole picture is considered in decisions (by bringing them early into the process, by making sure their concerns are understood and part of the global profit/cost calculation and making sure their experiences with the change are part of the evaluation).
You give people security by allowing them to predict and control things (by transparency about plans, how far the change will go and guaranteed transitions periods, by giving them enough time so they can actually plan and do the transition).
You give people security by avoiding early points of no return (by having wide enough tests, rollback scenarios,...).
You give people security by not letting them alone (by having good documentation, availability of training, ...).
Especially side-by-side availability of old and new is an extremely powerful tool, as it fits all of the above:
It allows people to actually test it (and not some little prototype mostly but not quite totally unrelated to reality) so their feedback can be heard. It makes it more predictable as all the new ways can be tried before the old ones no longer work. It is the ultimate role-back scenario (just switch off the new). And allows for learning the new before losing the old.
Of course giving the people a feeling of security needs resources. But it is a very powerful way to get people to embrace the chance.
Also in my experience people only fearing for themselves will usually mostly be passive by not pushing forward and trying to avoid or escape the changes.
(After all, working against something costs energy, so purely egoistic behavior is quite limiting in that regard).
Most people actively pushing back do it because they fear for something larger than only them. And any measure to making them fear less that you ruin the overall organization, not only avoids unnecessary hurdles rolling out the change but also has some small chance to actually avoid running into disaster with closed eyes.
A common way to build a firewall ruleset is to run a shell script
calling