Opened 13 years ago
Last modified 13 years ago
#1980 new defect
CPU Usage increases steadily while AUDIO is output to HDMI and ANALOG simulationusly
| Reported by: | Owned by: | reimar | |
|---|---|---|---|
| Priority: | normal | Component: | ao |
| Version: | unspecified | Severity: | normal |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Reproduced by developer: | no | Analyzed by developer: | no |
Description
Dear Group,
so I have a relatively current version of Mplayer MPlayer SVN-r32479-4.4.1. Wonderful peace of software though I'm facing a very strange problem when using the following .asoundrc file to dupe/output the sound to HDMI and Analog at the same time.
The -ao is alsa:device=default and it works, to have sound simultaneously on TV and Hifi. There's a little time offset of course cause the two cards are not synchronized. But that's okay for me, cause I only use either or.
So the issue is, that the CPU usage of Mplayer suddenly increases. That means per minute something like 5-10%. Tried to play around with buffer_sizes and times. No luck.
Can this be a synchronisation issue? Does anybody have an idea what this could be?
Btw:
ION 2 Platform with Intel(R) Atom(TM) CPU D510 @ 1.66GHz
Greetings,
Flo
# ~/.asoundrc or /etc/asound.conf
# ALSA configuration file
##### USAGE #####
# Save this file as "~/.asoundrc" (for user-specific sound configuration) or
# "/etc/asound.conf" (for system-wide sound configuration) and specify ALSA
# device names ad described in the next section.
##### DEVICE NAMES #####
# This configuration file defines four devices for use by the user. Those
# devices are "analog", "mixed-analog", "digital", and "mixed-digital". The
# user may also re-define "default" to be identical to one of the above-named
# devices (i.e. to send all sound output to the digital output unless otherwise
# specified). Use the device names as described below:
# - "analog" outputs to the analog output directly and (at least on software
# sound cards) blocks other audio output. After playback completes, "queued"
# sounds are output in sequence.
# - "mixed-analog" mixes audio output from multiple programs into the analog
# output (so you can hear beeps, alerts, and other noises while playing back
# an audio stream).
# - "digital" outputs to the digital output directly. Since most (all?)
# digital outputs expect 48kHz PCM audio, this may not work for some playback
# (i.e. CD's--which are 44.1kHz PCM audio--or 32kHz audio streams from TV
# recordings, etc.).
# - "mixed-digital"
# All other devices created within this file are used only by the configuration
# file itself and should /not/ be used directly. In other words, do not use
# the devices "analog-hw", "dmix-analog", "digital-hw", or "dmix-digital".
##### IMPORTANT #####
# To make this ALSA configuration file work with your sound card, you will need
# to define the appropriate card and device information for the "analog-hw" and
# "digital-hw" devices below. You can find the card and device information
# using "aplay -l".
# Alias for (converted) analog output on the card
# - This is identical to the device named "default"--which always exists and
# refers to hw:0,0 (unless overridden)
# - Therefore, we can specify "hw:0,0", "default", or "analog" to access analog
# output on the card
# - Note that as of ALSA 1.0.9, "software" sound card definitions redefine
# "default" to do mixing, meaning this device is different from "default" and
# allows playback while blocking other sound sources (until playback
# completes).
pcm.analog {
type plug
slave.pcm "analog-hw"
hint {
show on
description "Analog Output - Use analog outputs, converting samples, format, and rate as necessary."
}
}
# Control device (mixer, etc.) for the card
ctl.analog {
type hw
card 0
}
# Alias for (converted) mixed analog output on the card
# - This will accept audio input--regardless of rate--and convert to the rate
# required for the dmix plugin (in this case 48000Hz)
# - Note that as of ALSA 1.0.9, "software" sound card definitions redefine
# "default" to do mixing, meaning this device is identical to "default" for
# "software" sound cards.
pcm.mixed-analog {
type plug
slave.pcm "dmix-analog"
hint {
show on
description "Mixed Analog Output - Use analog outputs, converting samples, format, and rate as necessary. Allows mixing with system sounds."
}
}
# Control device (mixer, etc.) for the card
ctl.mixed-analog {
type hw
card 0
}
# Alias for (converted) digital (HDMI) output on the card
pcm.digital {
type plug
slave.pcm "digital-hw"
hint {
show on
description "Digital Output - Use digital outputs, converting samples, format, and rate as necessary."
}
}
# Control device (mixer, etc.) for the card
ctl.digital {
type hw
card 0
}
# Alias for mixed (converted) digital (HDMI) output on the card
pcm.mixed-digital {
type plug
slave.pcm "dmix-digital"
hint {
show on
description "Mixed Digital Output - Use digital outputs, converting samples, format, and rate as necessary. Allows mixing with system sounds."
}
}
# Control device (mixer, etc.) for the card
ctl.mixed-digital {
type hw
card 0
}
# The following devices are not useful by themselves. They require specific
# rates, channels, and formats. Therefore, you probably do not want to use
# them directly. Instead use of of the devices defined above.
# Alias for analog output on the card
# Do not use this directly--it requires specific rate, channels, and format
pcm.analog-hw {
type hw
card 0
device 0
}
# Control device (mixer, etc.) for the card
ctl.analog-hw {
type hw
card 0
}
# Alias for digital (HDMI) output on the card
# Do not use this directly--it requires specific rate, channels, and format
pcm.digital-hw {
type hw
card 1
device 7
}
# Control device (mixer, etc.) for the card
ctl.digital-hw {
type hw
card 1
}
# Direct software mixing plugin for analog output on the card
# Do not use this directly--it requires specific rate, channels, and format
pcm.dmix-analog {
type dmix
ipc_key 1234
slave {
pcm "analog-hw"
period_time 0
period_size 2048
buffer_size 65536
buffer_time 0
periods 128
rate 48000
channels 2
}
bindings {
0 0
1 1
}
slowptr true
}
# Control device (mixer, etc.) for the card
ctl.dmix-analog {
type hw
card 0
}
# Direct software mixing plugin for digital (S/PDIF) output on the card
# Do not use this directly--it requires specific rate, channels, and format
pcm.dmix-digital {
type dmix
ipc_key 1235
slave {
pcm "digital-hw"
period_time 0
period_size 2048
buffer_size 65536
buffer_time 0
periods 128
rate 48000
channels 2
}
bindings {
0 0
1 1
}
slowptr true
}
# Control device (mixer, etc.) for the card
ctl.dmix-digital {
type hw
card 0
}
# Make joint analog/HDMI the default
pcm.!default {
type plug
slave {
pcm multi
#rate 48000
}
ttable.0.0 1.0
ttable.1.1 1.0
ttable.0.2 1.0
ttable.1.3 1.0
}
# Control device (mixer, etc.) for the card
ctl.!default {
type hw
card 0
}
pcm.multi {
type multi
slaves.a.pcm "dmix-analog"
slaves.a.channels 2
slaves.b.pcm "dmix-digital"
slaves.b.channels 2
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}
ctl.multi {
type hw
card 0
}
Attachments (1)
Change History (6)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
comment:3 by , 13 years ago
Dear Reimar,
thanks for that fast reply.
So attached is the dump of the perf investigation of mplayer as you suggested.
As fas as I understand, it's libasound.so and [snd_pcm] where all the CPU load goes to.
How do you interpret the perf protocol?
Regarding your doubts about realizing the audio output on two different devices. I thought, that the fixed rate of 48000hz in the dmix part of asoundrc gives a fixed clock to the hardware devices. But I'm not into that topic that far, so this stays just a guess.
Do you have any other ideas how to implement a audio output on multiple soundcards?
Are there any other attempts to realize something like that? e.g. passing multiple -ao parameters to mplayer?
Greetings,
Flo
comment:4 by , 13 years ago
fixed rate of 48000hz in the dmix part of asoundrc
gives a fixed clock to the hardware devices
How would you define those 48kHz? It's not like there's an atomic clock hidden in dmix somewhere. So it has to take some clock.
Whichever it takes, at least one of the soundcard clocks will _not_ match it, thus it has to continuously adjust the resampling.
The perf log actually shows the largest value for sysenter_past_esp, which I think is basically syscall overhead.
Could you describe more in detail how CPU usage increases? Is there some upper limit to how much CPU it uses?
I suspect ALSA might be overzealous in reading out soundcard state in order to synchronize them (possibly also due to MPlayer querying playback position quite often? Pure speculation).
I think you should try to ask the ALSA guys about this, though maybe trying to play something with aplay first to see if the same happens there is a good idea.
Other things you could try:
1) A 64 bit system with 64 bit MPlayer. Syscalls are faster there...
2) Setting this spreading to two outputs up via JACK or pulseaudio (I do not like them much, but they were designed for that kind of thing - well, pulseaudio maybe more for transparently switching between output devices).
comment:5 by , 13 years ago
Hi Reimar,
thanks for your thoughts on that.
The perf log actually shows the largest value for sysenter_past_esp, which I
think is basically syscall overhead.
Could you describe more in detail how CPU usage increases? Is there some upper
limit to how much CPU it uses?
I don't have the impression that there's a upper limit. Can't say if there's still an overhead created when the cpu usage viewed with top is already at 100%.
I suspect ALSA might be overzealous in reading out soundcard state in order to
synchronize them (possibly also due to MPlayer querying playback position quite
often? Pure speculation).
I think you should try to ask the ALSA guys about this, though maybe trying to
play something with aplay first to see if the same happens there is a good
idea.
I'll do both of it and keep you informed.
Other things you could try:
1) A 64 bit system with 64 bit MPlayer. Syscalls are faster there...
2) Setting this spreading to two outputs up via JACK or pulseaudio (I do not
like them much, but they were designed for that kind of thing - well,
pulseaudio maybe more for transparently switching between output devices).
I already tried Pulseaudio but couldn't get it to work with my configuration. Same for JACK. If I find some time I'll definitely try it again.
Cheers,
FS
I have some serious doubts this can work, the devices have different clocks and over time will need completely different parts of the audio to play.
ALSA could resample one of them dynamically to match up their speed (which _might_ cause a highish and rather volatile CPU load I'd expect), though I do not know about that. Even if it does, the "buffer free" and latency information has a chance of becoming unreliable which would also cause problems with MPlayer.
If you build a debug version and then use "perf record [mplayer command]" and then "perf report" that should list where all the CPU time goes to.