Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a headless machine connected to my sound system, and I am using it to run a music playing daemon that I control over the network. (Among other things)

However, I can't seem to be able to have sound come out of my speakers without running X.

I am running pulse audio in a system wide instance and my daemon is not running within X. Nevertheless, when my daemon is playing music without me hearing it, I can fix it by running startx in an unrelated session. After X starts, I can hear the sound. The sound disappears again if I kill the X server.

Interestingly/annoyingly, the sound also stops after X has been running for a few minutes. This could possibly be because of a screen saver of some sort, but I haven't been able to verify or falsify this theory.

So my current workaround is to ssh into the box whenever I want music and startx, and restart it every fifteen minutes or so. I'd like to do better.

I have been able to verify the following:

  • Adjustments in alsamixer have no effect on this problem. The relevant output channel is never muted
  • In alsamixer, I can see no difference between when the sound is working and when it isn't
  • Nothing is muted in pactl list
  • There is no difference in the output from pactl list between before starting X and after it's started. (Except the identifier of the pactl instance connected to pulse, which is different each time you run pactl)
  • The user running the music daemon is a member of the groups audio, pulse and pulse-access
  • The music daemon program does not report any error messages and acts as if it is playing the music like it should
  • Some form of dbus daemon is running. ps aux|grep dbus reports dbus-daemon --system --fork --activation=upstart before and after I have started X

Some details about my hardware:

Output of lsmod:

Module                  Size  Used by
deflate                12617  0 
zlib_deflate           27139  1 deflate
ctr                    13201  0 
twofish_generic        16635  0 
twofish_x86_64_3way    25287  0 
twofish_x86_64         12907  1 twofish_x86_64_3way
twofish_common         20919  3 twofish_generic,twofish_x86_64_3way,twofish_x86_64
camellia               29348  0 
serpent                29125  0 
blowfish_generic       12530  0 
blowfish_x86_64        21466  0 
blowfish_common        16739  2 blowfish_generic,blowfish_x86_64
cast5                  25112  0 
des_generic            21415  0 
xcbc                   12815  0 
rmd160                 16744  0 
bnep                   18281  2 
rfcomm                 47604  12 
sha512_generic         12796  0 
crypto_null            12918  0 
parport_pc             32866  0 
af_key                 36389  0 
ppdev                  17113  0 
binfmt_misc            17540  1 
nfsd                  281980  2 
ext2                   73795  1 
nfs                   436929  1 
lockd                  90326  2 nfsd,nfs
fscache                61529  1 nfs
auth_rpcgss            53380  2 nfsd,nfs
nfs_acl                12883  2 nfsd,nfs
sunrpc                255224  16 nfsd,nfs,lockd,auth_rpcgss,nfs_acl
btusb                  18332  2 
vesafb                 13844  2 
pl2303                 17957  1 
ath3k                  12961  0 
bluetooth             180153  24 bnep,rfcomm,btusb,ath3k
snd_hda_codec_hdmi     32474  4 
nvidia              11308613  0 
ftdi_sio               40679  1 
usbserial              47113  6 pl2303,ftdi_sio
psmouse                97485  0 
snd_hda_codec_realtek   224173  1 
snd_hda_intel          33719  5 
snd_hda_codec         127706  3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
serio_raw              13211  0 
snd_seq_midi           13324  0 
snd_hwdep              17764  1 snd_hda_codec
snd_pcm                97275  3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_rawmidi            30748  1 snd_seq_midi
snd_seq_midi_event     14899  1 snd_seq_midi
snd_seq                61929  2 snd_seq_midi,snd_seq_midi_event
snd_timer              29990  2 snd_pcm,snd_seq
snd_seq_device         14540  3 snd_seq_midi,snd_rawmidi,snd_seq
snd                    79041  20 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
asus_atk0110           18078  0 
mac_hid                13253  0 
jc42                   13948  0 
soundcore              15091  1 snd
snd_page_alloc         18529  2 snd_hda_intel,snd_pcm
coretemp               13554  0 
i2c_i801               17570  0 
lp                     17799  0 
parport                46562  3 parport_pc,ppdev,lp
r8169                  62154  0 

Any ideas? What does X do that's so important?

share|improve this question
I can not give you a solution here but a hint in a comment is better than nothing. You may not have dbus running which is usually started with X but pulseaudio needs the dbus. – Takkat Jun 24 '13 at 19:15
@Takkat ps aux |grep dbus gives me one hit (in addition to grep...) regardless of whether or not X is running: dbus-daemon --system --fork --activation=upstart. Is this sufficient to conclude that dbus is not the problem? – Magnus Hoff Jun 24 '13 at 19:49
Well, then dbus may not be the problem. – Takkat Jun 24 '13 at 19:56
Not an answer, a suggestion: If your machine is only used as a headless remote controlled media player, you can try to disable pulseaudio completely. Pulseaudio is used for software mixing, audio over network support and abstraction of the OS's audio API. The only one you might maybe eventually need for a remote controlled media player is software mixing, and ALSA can do this with the dmix plugin. Only if dmix is not enabled per default on your system (depends on the soundcard) and you need software mixing, you might be better off using pulseaudio, for manually configuring ALSA can be a pain. – soulsource Jun 24 '13 at 19:58
@soulsource Straight ALSA is definitely an alternative, but I bumped into problems there as well, so for now I'm trying to solve the pulse-stuff... if I can :) – Magnus Hoff Jun 24 '13 at 20:08
up vote 2 down vote accepted

The HDMI output is managed by the graphics driver, which in your case is the closed-source driver from Nvidia. Apparently, that driver enables the HDMI audio encoder only when X is running.

Complain to Nvidia.

Alternatively, use your motherboard's S/PDIF output.

Addendum by asker, Magnus Hoff:

Pursuing this angle further, I ended up running X but disabling dpms, so the HDMI output is maintained at its powered, fully functional state. I realized I had to do this from reading documentation by nvidia.

To make this happen, I added the following to my .xinitrc:

xset s off
xset -dpms


share|improve this answer
Yeah, it seems you are onto something: "Note that the NVIDIA binary X driver is specifically an X driver. For this reason, steps 2 and 3 (and indeed 1) are only activated when the X server is running, and actively controls the VT. When X is not active, or when the console is VT-switched to a text terminal, HDMI audio will not work."… – Magnus Hoff Jun 25 '13 at 15:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.