You are not logged in.
Pages: 1
Topic closed
Hi! Skype 4.3 is announced to support pulseaudio only (alsa support is removed). To prepare to upcoming upgrade I have played with pulse + skype. To keep all alsa setup (I have three cards) I have just assign two alsa devices (dmix and dsnoop) to pulse's sink and source
load-module module-alsa-sink device=iceDmixer
load-module module-alsa-source device=iceDsnoop
All does work as expected except for big delay (on the my side) of sound against video resulting also in unacceptable echo (on the other - my respondent's - side).
I'm aware of delay defined in .desktop file, but delay duration is hundreds ms (I guess 500-700 ms) rather 60ms.
Any ideas to resolve?
P.S. Resolution: with skype 4.3 the issue is almost gone.
Last edited by student975 (2014-06-26 23:50:50)
"I exist" is the best myth I know..
Offline
You add the alsamixers as default cards to pulseaudio which is itself a mixer now you are mixing the audio twice and this obviously gives you shitton of latency. The whole point of pulse is to not have to worry as much about the internals of alsa, back up your asound.conf and install pulseaudio-alsa. The only entry you need in asound.conf while using pulse is
# Use PulseAudio by default
pcm.!default {
type pulse
fallback "sysdefault"
hint {
show on
description "Default ALSA Output (currently PulseAudio Sound Server)"
}
}
ctl.!default {
type pulse
fallback "sysdefault"
}
which pulseaudio-alsa will automatically set up. To set preferred sound cards you can use pavucontrol or pactl or use the load-module method where the device name corresponds to hw:0,0 or whatever the correct indexes are from what aplay -l tells you. Though I'm fairly certain the last method should only be used if absolutely necessary which is not the case in most cases. Also note that you can freely pass around soundstreams across your cards, and that whatever card you passed a stream to will be saved as playback device once that stream reappears so if you have certain audio clients you'd rather have playing on a different card than default, open the stream and then pass it to another card using pavucontrol/pactl
Offline
now you are mixing the audio twice and this obviously gives you shitton of latency
Sorry, something wrong with my math. Normal latency for mixing is from zero samples (say, HDSP mixer) up to a dozen ms in JACK server and also something sonically zero (don't know exactly, but it is almost zero ) for dmixer. Taking it twice we will not get hundreds of ms.
It is a list of sinks at the moment of test skype call. There *are* latencies.
~ $ pacmd list-sink-inputs
2 sink input(s) available.
index: 0
driver: <module-combine-sink.c>
flags: VARIABLE_RATE DONT_MOVE NO_CREATE_SUSPEND
state: RUNNING
sink: 0 <alsa_output.dmix>
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
muted: no
current latency: 0.00 ms
requested latency: 200.00 ms
sample spec: s16le 2ch 44100Hz
channel map: front-left,front-right
Stereo
resample method: trivial
module: 11
properties:
media.name = "Simultaneous output on VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (Aureon 7.1 Space)"
media.role = "filter"
module-stream-restore.id = "sink-input-by-media-role:filter"
index: 3
driver: <protocol-native.c>
flags: START_CORKED
state: RUNNING
sink: 1 <combined>
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
muted: no
current latency: 217.88 ms
requested latency: 200.00 ms
sample spec: s16le 2ch 48000Hz
channel map: front-left,front-right
Stereo
resample method: speex-float-1
module: 8
client: 10 <Skype>
properties:
window.icon_name = "skype"
application.icon_name = "skype"
media.role = "phone"
media.name = "Output"
application.name = "Skype"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "29"
application.process.id = "2139"
application.process.user = "anli"
application.process.host = "jazz"
application.process.binary = "skype"
application.language = "en_US.UTF-8"
window.x11.display = ":0"
application.process.machine_id = "07c622b729d500bbcb3a0c8d00000427"
application.process.session_id = "c1"
module-stream-restore.id = "sink-input-by-media-role:phone"
Am I wrong?
Last edited by student975 (2014-06-21 19:48:50)
"I exist" is the best myth I know..
Offline
Hmm that looks really strange I get at most 100 ms, but yeah it seems like using dmix as the source isn't really the source of the problem... don't know then but if microsoft have done their job this will most likely fix itself when the update comes and the need for PULSE_LATENCY_MSEC=60 should be obsolete (on a related note, do you have that set? it has been removed as default from the newer packages and skype tends to do weird shit if it isn't actually present, depending on your soundcard)
Offline
Yes, I have that setting in the desktop file, and to be sure I added export of this setting into ~/.bash_profile with the same result.
~ $ cat /usr/share/applications/skype.desktop
[Desktop Entry]
Name=Skype
Comment=Skype Internet Telephony
Exec=env PULSE_LATENCY_MSEC=60 skype %U
Icon=skype.png
Terminal=false
Type=Application
Encoding=UTF-8
Categories=Network;Application;
MimeType=x-scheme-handler/skype;
X-KDE-Protocols=skype
"I exist" is the best myth I know..
Offline
The situation is the same with skype 4.3 (it is in the official repo now).
"I exist" is the best myth I know..
Offline
Aside from trying without dmix as the soundcard I don't really have anything to offer, I'm pretty sure I've read somewhere that dmix does introduce some latency because it can't know what clients will want what kind of latency beforehand and in order to mix effectively it has a set default value and pulse will add it's own mixing capabilities on top of that. I don't remember where I've read this, so take this with a grain of salt (for completeness sake you don't have tsched=0 set in pulse I hope? this also introduces latency)
Offline
Aside from trying without dmix as the soundcard I don't really have anything to offer, I'm pretty sure I've read somewhere that dmix does introduce some latency because it can't know what clients will want what kind of latency beforehand and in order to mix effectively it has a set default value and pulse will add it's own mixing capabilities on top of that. I don't remember where I've read this, so take this with a grain of salt (for completeness sake you don't have tsched=0 set in pulse I hope? this also introduces latency)
No, I haven't set tsched at all. I'll try direct alsa device (aka hw:0,0) tomorrow when my respondents will wake up.
"I exist" is the best myth I know..
Offline
As for using hw instead of dmix device - I have not noticed any difference.
Last edited by student975 (2014-06-26 23:50:37)
"I exist" is the best myth I know..
Offline
This post is already old, but just in case someone else has a similar problem:
I (or rather my interlocutors) also experienced echos in Skype (for some reason not in test calls, only in real calls). For me, setting tsched=0 as described here seems to have fixed the issue: https://wiki.archlinux.org/index.php/Pu … _crackling.
Offline
Don't necrobump, specially when you are not adding anything new.
Closing.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1
Topic closed