Summary: | Stuttering when using "Simultaneous output" | ||
---|---|---|---|
Product: | PulseAudio | Reporter: | Tanu Kaskinen <tanuk> |
Component: | modules | Assignee: | pulseaudio-bugs |
Status: | RESOLVED FIXED | QA Contact: | pulseaudio-bugs |
Severity: | normal | ||
Priority: | medium | CC: | dpc, lennart, matthias.sweertvaegher, Olli-D, wim.taymans |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
pulseverbose.log
Firefox with flash audio stuttering Chrome with flash audio not suttering Chrome and flash with stuttering sound possible patch Improved patch Improved patch Improved patch |
Description
Tanu Kaskinen
2012-03-26 07:04:40 UTC
Comment from ngoonee on 2010-08-09: I too have noticed this, but only with heavy-CPU usage apps. As a non-coder, my uninformed opinion is that the simultaneous output plugin is not running at the same priority level as the rest of pulse. Examples of apps - Starcraft II in wine (older games run fine) and VLC playing simultaneously to bluetooth and internal audio card (used to have a problem, but I think the VLC folks decreased resource load recently, works fine right now). Comment from davydm on 2012-03-24: I'd love to know the status of this problem. I'm running Linux Mint 12 here, with installed pulseaudio version 1:1.0-0ubuntu3.1, experiencing exactly this problem with games like World of Goo and Osmos, from the Humble Bundle. Leaving the volume control app open "fixes" the problem, but I saw mention at http://answerpot.com/showthread.php?838648-Audio+will+stutter+unless+Volume+Control+is+running of possible buffering or priority issues. I've bumped the pulseaudio process's nice as high as it can go -- as well as, just for chuckles, ionice. No change. If this is a buffering issue, is there some way I can get pulseaudio to run with these settings by default? I'm not seeing any downside to this solution -- in fact, if the volume control app "fixes" the issue whilst it's open, I'm curious to know why the daemon hasn't just been modified to run as it does when the volume control app is open? I can't be the only user pulling my hair out about this and I tend to use simultaneous output so I can switch, with hardware, between usb headphones and my desktop speakers (night/day time), so it's quite important to me, at least (: Let me know if there is any diagnostic I can run or any patches I can try. I am a programmer, but I would be the first to admit that I don't know the first thing about the PA code base or architecture. (In reply to comment #2) > Comment from davydm on 2012-03-24: > > I'd love to know the status of this problem. I'm running Linux Mint 12 here, > with installed pulseaudio version 1:1.0-0ubuntu3.1, experiencing exactly this > problem with games like World of Goo and Osmos, from the Humble Bundle. Status: quite possibly nothing has improved. > Leaving the volume control app open "fixes" the problem, but I saw mention at > http://answerpot.com/showthread.php?838648-Audio+will+stutter+unless+Volume+Control+is+running > of possible buffering or priority issues. I've bumped the pulseaudio process's > nice as high as it can go -- as well as, just for chuckles, ionice. No change. > If this is a buffering issue, is there some way I can get pulseaudio to run > with these settings by default? I'm not seeing any downside to this solution -- > in fact, if the volume control app "fixes" the issue whilst it's open, I'm > curious to know why the daemon hasn't just been modified to run as it does when > the volume control app is open? The volume control app makes wakeups more frequent, which increases CPU consumption, so we don't want to do that when we don't have to. Now, you could argue that there should be some configuration option that forces small buffers, but what really should be done is to fix the bug so that everyone is happy without needing to configure anything. > I can't be the only user pulling my hair out > about this and I tend to use simultaneous output so I can switch, with > hardware, between usb headphones and my desktop speakers (night/day time), so > it's quite important to me, at least (: Can you explain a bit more why you need module-combine-sink ("simultaneous output") to achieve this? On standard Gnome, switching between devices should be as simple as opening Sound Settings, selecting the Output tab and selecting another device. AFAIK Ubuntu doesn't use standard Gnome, but I'd expect it not to be very different. > Let me know if there is any diagnostic I can run or any patches I can try. I am > a programmer, but I would be the first to admit that I don't know the first > thing about the PA code base or architecture. Pulseaudio log might be useful. Ubuntu provides a nice page explaining how to get that: https://wiki.ubuntu.com/PulseAudio/Log > The volume control app makes wakeups more frequent, which increases CPU > consumption, so we don't want to do that when we don't have to. Now, you could > argue that there should be some configuration option that forces small buffers, > but what really should be done is to fix the bug so that everyone is happy > without needing to configure anything. I'm all for that, but would settle for a workaround, to be honest (: I'm also a bit pedantic when I program, so trust me that I understand that such a workaround would probably irk you or whoever worked it in -- but it's something I would appreciate. Not to harp on, but if I knew off-hand (or with little investigation) how to duplicate this in another application, I would have already written a workaround app to launch alongside my session to "fix" this (: Hacky? Sure! But scratches the itch -- for now. > Can you explain a bit more why you need module-combine-sink ("simultaneous > output") to achieve this? On standard Gnome, switching between devices should > be as simple as opening Sound Settings, selecting the Output tab and selecting > another device. AFAIK Ubuntu doesn't use standard Gnome, but I'd expect it not > to be very different. The PulseAudio application to manage default sinks and the like doesn't actually work "as expected" for me. I should probably log another bug, but what I get is that every application is default assigned to my internal audio device (despite setting combined as the default sink) until such time as I manually switch that application to combined. It's much easier if everything is on combined to just turn down the hardware knob on my speaker set if I want to use the headphones than to open up pavucontrol (iirc that's the program?) and switch each app over to my USB headset and back again so that when my wife uses the computer the next day, things work "as expected" for her. In addition, this simultaneous output feature is the one thing I wish that would be implemented in the windows sound system, for exactly the same reason. Instead of multiple clicks, I can just reach for the hardware knob and turn off the speakers. I work around it in windows by having a scheduled task to switch devices (since I want to use headphones at night) -- something I tried with PA and, though I got the default device to switch, the setting wouldn't be applied to all running apps -- I had to switch each individual app (fine, I worked that one out) but the whole script just seemed flaky -- sometimes it worked, sometimes it didn't, with the same logic, mere seconds apart. I gave up since I program all day and just wanted to relax at night (: > Pulseaudio log might be useful. Ubuntu provides a nice page explaining how to > get that: https://wiki.ubuntu.com/PulseAudio/Log I'll get some posted on here when I'm back in Linux -- switched to that other OS for the moment to game (: Hi, I'm also affected by this on Ubuntu 12.10 x64. BTW. I think that audio combining should be the default behavior. It's usually much simpler and natural for the user to turn on/off the device that should be playing sound, instead of changing some option. Especially that sometimes (e.g. playing a game) one can not change settings. Created attachment 74241 [details]
pulseverbose.log
Here goes the log, when I started pulseaudio and aferwards played a Deezer (flash on Google Chrome) for 5-10 seconds.
Created attachment 76874 [details]
Firefox with flash audio stuttering
Have the same stuttering as others describe here, but only in some(?) flash sources in Firefox. Other sound sources are fine. Running pavucontrol makes the problem go away.
This attachment is from:
Ubuntu 12.10 x64
Firefox 19.0.2
Flash 11.2.r202
pulseaudio 2.1
The reason for having combined outputs is convenience. I can change to watching something on my TV by just changing source on the TV, and not also having to fiddle around with pavucontrol.
Created attachment 76875 [details]
Chrome with flash audio not suttering
As above, but with Chrome 25.0.1364.172 and its more updated flash 11.6.602.180.
Created attachment 76983 [details]
Chrome and flash with stuttering sound
Hi,
same problem here.
Configured Pulseaudio with simultaneous output on HDMI (nvidia) and HDA Intel (Realtek codec) analog stereo.
Attached log file from test with Chromium and flash running a video stream from the internet.
With pavucontrol openend and restarting chrome the stuttering vanishes.
Without simultaneous output and testing each output seperatly, everything works smooth.
I have also tried pulseaudio-2.1-r1 with realtime USE-flag and pulseaudio-3.0 with same result...sound is still stuttering under high load.
regards,
Kontr-Olli
latest Gentoo system.
[ebuild R ] media-sound/pulseaudio-2.1-r1 USE="X alsa asyncns bluetooth caps dbus equalizer gdbm glib gnome gtk libsamplerate orc ssl tcpd udev webrtc-aec -avahi -doc -ipv6 -jack -lirc (-oss) -realtime (-system-wide) (-systemd) {-test} -xen" 0 kB
[ebuild R ] www-client/chromium-25.0.1364.160 USE="cups gnome-keyring -bindist -custom-cflags -gnome -kerberos (-pulseaudio) (-selinux) (-system-ffmpeg) (-tcmalloc) {-test}" LINGUAS="de -am -ar -bg -bn -ca -cs -da -el -en_GB -es -es_LA -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt_BR -pt_PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh_CN -zh_TW" 0 kB
[ebuild R ] www-plugins/adobe-flash-11.2.202.275 USE="64bit (multilib) sse2check vdpau -32bit -kde (-selinux)" 0 kB
lapp-Kontr-Olli Desktop # lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05)
01:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
Kernel:
3.7.10-gentoo #2 SMP
with Kernel Config for ALSA:
<*> HR-timer backend support
│ │ [*] Use HR-timer as default sequencer timer
with Kernel Config for Intel HD:
(2048) Pre-allocated buffer size for HD-audio driver
[*] Support initialization patch loading for HD-audio
[*] Build Realtek HD-audio codec support
[*] Support jack plugging notification via input layer
-*- Build hwdep interface for HD-audio driver
-*- Allow dynamic codec reconfiguration (EXPERIMENTAL)
[*] Build HDMI/DisplayPort HD-audio codec support
(60) Default time-out for HD-audio power-save mode
(In reply to comment #9) > Created attachment 76983 [details] > Chrome and flash with stuttering sound > > Hi, > > same problem here. > Configured Pulseaudio with simultaneous output on HDMI (nvidia) and HDA > Intel (Realtek codec) analog stereo. beside the audio clock at different cards are not run in same speed Nvidia has alignment of period size of 128 bytes but intel hda controller don't has this limitation ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: Slave: Hardware PCM card 1 'HDA NVidia' device 3 subdevice 0 ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: Its setup is: ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: stream : PLAYBACK ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: access : MMAP_INTERLEAVED ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: format : S16_LE ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: subformat : STD ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: channels : 2 ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: rate : 44100 ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: exact rate : 44100 (44100/1) ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: msbits : 16 ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: buffer_size : 88192 ( 0.286| 0.000) D: [pulseaudio] alsa-util.c: period_size : 44096 ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: Slave: Hardware PCM card 0 'HDA Intel MID' device 0 subdevice 0 ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: Its setup is: ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: stream : PLAYBACK ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: access : MMAP_INTERLEAVED ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: format : S16_LE ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: subformat : STD ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: channels : 2 ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: rate : 44100 ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: exact rate : 44100 (44100/1) ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: msbits : 16 ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: buffer_size : 88200 ( 0.344| 0.000) D: [pulseaudio] alsa-util.c: period_size : 44100 (In reply to comment #10) > (In reply to comment #9) > > Created attachment 76983 [details] > > Chrome and flash with stuttering sound > > > > Hi, > > > > same problem here. > > Configured Pulseaudio with simultaneous output on HDMI (nvidia) and HDA > > Intel (Realtek codec) analog stereo. > > beside the audio clock at different cards are not run in same speed > > Nvidia has alignment of period size of 128 bytes > but intel hda controller don't has this limitation > > Thanks for clarification.... is there a way to configure the period-size for both sources to match the 128bytes alignement? do I have to do this in alsa config or in the pulse-audio config? maybe you could give a hint, where to change the parameter of the two sources in order to get equal-spaced alignment... thanks in advance.. Kontr-Olli do module-combine still work when you also load module-switch-on-port-available ? ( 0.434| 0.011) D: [pulseaudio] module-gconf.c: Loading module 'module-combine' with args '' due to GConf configuration. ( 0.434| 0.000) W: [pulseaudio] module.c: module-combine is deprecated: Please use module-combine-sink instead of module-combine! ( 0.434| 0.000) W: [pulseaudio] module-combine.c: We will now load module-combine-sink. Please make sure to remove module-combine from your configuration. ( 0.415| 0.000) D: [pulseaudio] module-alsa-card.c: Found 6 jacks. ( 0.416| 0.000) I: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:0' ( 0.416| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Front Headphone Jack' is now unplugged ( 0.416| 0.000) D: [pulseaudio] device-port.c: Setting port analog-output-headphones to status no ( 0.416| 0.000) D: [pulseaudio] core-subscribe.c: Dropped redundant event due to change event. ( 0.416| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'HDMI/DP,pcm=3 Jack' is now unplugged ( 0.416| 0.000) D: [pulseaudio] device-port.c: Setting port hdmi-output-0 to status no ( 0.416| 0.000) D: [pulseaudio] core-subscribe.c: Dropped redundant event due to change event. ( 0.416| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'HDMI/DP,pcm=7 Jack' is now unplugged ( 0.416| 0.000) D: [pulseaudio] device-port.c: Setting port hdmi-output-1 to status no ( 0.417| 0.000) D: [pulseaudio] core-subscribe.c: Dropped redundant event due to change event. ( 0.417| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Front Mic Jack' is now unplugged ( 0.417| 0.000) D: [pulseaudio] device-port.c: Setting port analog-input-microphone-front to status no ( 0.417| 0.000) D: [pulseaudio] core-subscribe.c: Dropped redundant event due to change event. ( 0.417| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Rear Mic Jack' is now plugged in ( 0.417| 0.000) D: [pulseaudio] device-port.c: Setting port analog-input-microphone-rear to status yes ( 0.417| 0.000) D: [pulseaudio] core-subscribe.c: Dropped redundant event due to change event. ( 0.417| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Line Jack' is now unplugged ( 0.417| 0.000) D: [pulseaudio] device-port.c: Setting port analog-input-linein to status no ( 0.453| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port hdmi-output-1 ( 0.453| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port hdmi-output-2 ( 0.453| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port hdmi-output-3 ( 0.453| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port analog-output-headphones ( 0.453| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port analog-input-microphone-front ( 0.453| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port analog-input-linein ( 0.454| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port hdmi-output-0 ( 0.454| 0.000) D: [pulseaudio] module-switch-on-port-available.c: finding port hdmi-output-1 ( 0.454| 0.000) I: [pulseaudio] module.c: Loaded "module-switch-on-port-available" (index: #21; argument: ""). (In reply to comment #12) > do module-combine still work when you also load > module-switch-on-port-available ? Hi, I've added the following line to "/etc/pulse/system.pa" #test load-module module-switch-on-port-available and restarted pulse-server....but same result, module-combine still works, but is still stuttering...again, opening audio-mixer and restarting flash-video helps to work-around... regards, Kontr-Olli http://www.alsa-project.org/main/index.php/XRUN_Debug 16 Dump positions on each hardware pointer update call you can enable xrun_debug on both cards to check whether the hwptr are in sync on each hardware pointer update call (In reply to comment #14) > you can enable xrun_debug on both cards to check whether the hwptr are in > sync on each hardware pointer update call Hi, I've enabled xrun_debug on both cards: => echo 16 > card0/pcm0p/xrun_debug => echo 16 > card1/pcm7p/xrun_debug There were serveral pcmXp's in card1 section....but only one with sub0/status state: RUNNING...all other were "closed" I've played a flash-video again....here is the output of dmesg during playback: [ 1401.479793] hwptr_update: pcmC1D7p:0: pos=62612/44096/88192, hwptr=1/49097363/49097364/49034752 [ 1401.668545] hwptr_update: pcmC0D0p:0: pos=66294/44100/88200, hwptr=8316/49097178/49105494/49039200 [ 1401.668547] hwptr_update: pcmC1D7p:0: pos=70927/44096/88192, hwptr=8315/49097364/49105679/49034752 [ 1401.669106] hwptr_update: pcmC1D7p:0: pos=70952/44096/88192, hwptr=25/49105679/49105704/49034752 [ 1401.669108] hwptr_update: pcmC0D0p:0: pos=66320/44100/88200, hwptr=26/49105494/49105520/49039200 [ 1401.669125] hwptr_update: pcmC0D0p:0: pos=66320/44100/88200, hwptr=0/49105520/49105520/49039200 [ 1401.669126] hwptr_update: pcmC1D7p:0: pos=70953/44096/88192, hwptr=1/49105704/49105705/49034752 [ 1401.858799] hwptr_update: pcmC0D0p:0: pos=74676/44100/88200, hwptr=8356/49105520/49113876/49039200 [ 1401.858803] hwptr_update: pcmC1D7p:0: pos=79309/44096/88192, hwptr=8356/49105705/49114061/49034752 [ 1401.860107] hwptr_update: pcmC1D7p:0: pos=79367/44096/88192, hwptr=58/49114061/49114119/49034752 [ 1401.860111] hwptr_update: pcmC0D0p:0: pos=74733/44100/88200, hwptr=57/49113876/49113933/49039200 [ 1401.860131] hwptr_update: pcmC0D0p:0: pos=74734/44100/88200, hwptr=1/49113933/49113934/49039200 [ 1401.860135] hwptr_update: pcmC1D7p:0: pos=79368/44096/88192, hwptr=1/49114119/49114120/49034752 [ 1401.958528] hwptr_update: pcmC0D0p:0: pos=79070/44100/88200, hwptr=4336/49113934/49118270/49039200 [ 1401.958639] hwptr_update: pcmC1D7p:0: pos=83708/44096/88192, hwptr=4340/49114120/49118460/49034752 [ 1401.958903] hwptr_update: pcmC0D0p:0: pos=79086/44100/88200, hwptr=16/49118270/49118286/49039200 [ 1401.958914] hwptr_update: pcmC0D0p:0: pos=79086/44100/88200, hwptr=0/49118286/49118286/49039200 [ 1401.958927] hwptr_update: pcmC1D7p:0: pos=83721/44096/88192, hwptr=13/49118460/49118473/49034752 [ 1401.958937] hwptr_update: pcmC1D7p:0: pos=83721/44096/88192, hwptr=0/49118473/49118473/49034752 [ 1401.958941] hwptr_update: pcmC0D0p:0: pos=79088/44100/88200, hwptr=2/49118286/49118288/49039200 [ 1401.958949] hwptr_update: pcmC0D0p:0: pos=79088/44100/88200, hwptr=0/49118288/49118288/49039200 [ 1401.959187] hwptr_update: pcmC0D0p:0: pos=79098/44100/88200, hwptr=10/49118288/49118298/49039200 [ 1401.959200] hwptr_update: pcmC0D0p:0: pos=79099/44100/88200, hwptr=1/49118298/49118299/49039200 [ 1401.959630] hwptr_update: pcmC0D0p:0: pos=79119/44100/88200, hwptr=20/49118299/49118319/49039200 [ 1401.959639] hwptr_update: pcmC0D0p:0: pos=79119/44100/88200, hwptr=0/49118319/49118319/49039200 [ 1401.959667] hwptr_update: pcmC0D0p:0: pos=79120/44100/88200, hwptr=1/49118319/49118320/49039200 [ 1401.959672] hwptr_update: pcmC0D0p:0: pos=79120/44100/88200, hwptr=0/49118320/49118320/49039200 [ 1401.959937] hwptr_update: pcmC0D0p:0: pos=79132/44100/88200, hwptr=12/49118320/49118332/49039200 [ 1401.959944] hwptr_update: pcmC0D0p:0: pos=79132/44100/88200, hwptr=0/49118332/49118332/49039200 [ 1401.959979] hwptr_update: pcmC0D0p:0: pos=79133/44100/88200, hwptr=1/49118332/49118333/49039200 [ 1401.959988] hwptr_update: pcmC0D0p:0: pos=79134/44100/88200, hwptr=1/49118333/49118334/49039200 [ 1401.960235] hwptr_update: pcmC0D0p:0: pos=79145/44100/88200, hwptr=11/49118334/49118345/49039200 [ 1401.960245] hwptr_update: pcmC0D0p:0: pos=79145/44100/88200, hwptr=0/49118345/49118345/49039200 [ 1401.960271] hwptr_update: pcmC0D0p:0: pos=79146/44100/88200, hwptr=1/49118345/49118346/49039200 [ 1401.960281] hwptr_update: pcmC0D0p:0: pos=79147/44100/88200, hwptr=1/49118346/49118347/49039200 [ 1401.960493] hwptr_update: pcmC0D0p:0: pos=79156/44100/88200, hwptr=9/49118347/49118356/49039200 [ 1401.960505] hwptr_update: pcmC0D0p:0: pos=79157/44100/88200, hwptr=1/49118356/49118357/49039200 [ 1401.960529] hwptr_update: pcmC0D0p:0: pos=79158/44100/88200, hwptr=1/49118357/49118358/49039200 [ 1401.960538] hwptr_update: pcmC0D0p:0: pos=79158/44100/88200, hwptr=0/49118358/49118358/49039200 [ 1401.960741] hwptr_update: pcmC0D0p:0: pos=79167/44100/88200, hwptr=9/49118358/49118367/49039200 [ 1401.960752] hwptr_update: pcmC0D0p:0: pos=79167/44100/88200, hwptr=0/49118367/49118367/49039200 [ 1401.960788] hwptr_update: pcmC0D0p:0: pos=79169/44100/88200, hwptr=2/49118367/49118369/49039200 [ 1401.960798] hwptr_update: pcmC0D0p:0: pos=79170/44100/88200, hwptr=1/49118369/49118370/49039200 [ 1401.961087] hwptr_update: pcmC0D0p:0: pos=79182/44100/88200, hwptr=12/49118370/49118382/49039200 [ 1401.961099] hwptr_update: pcmC0D0p:0: pos=79183/44100/88200, hwptr=1/49118382/49118383/49039200 [ 1401.961127] hwptr_update: pcmC0D0p:0: pos=79184/44100/88200, hwptr=1/49118383/49118384/49039200 [ 1401.961138] hwptr_update: pcmC0D0p:0: pos=79185/44100/88200, hwptr=1/49118384/49118385/49039200 [ 1401.961418] hwptr_update: pcmC0D0p:0: pos=79197/44100/88200, hwptr=12/49118385/49118397/49039200 [ 1401.961431] hwptr_update: pcmC0D0p:0: pos=79198/44100/88200, hwptr=1/49118397/49118398/49039200 [ 1401.961457] hwptr_update: pcmC0D0p:0: pos=79199/44100/88200, hwptr=1/49118398/49118399/49039200 [ 1401.961468] hwptr_update: pcmC0D0p:0: pos=79200/44100/88200, hwptr=1/49118399/49118400/49039200 [ 1401.961680] hwptr_update: pcmC0D0p:0: pos=79209/44100/88200, hwptr=9/49118400/49118409/49039200 [ 1401.961689] hwptr_update: pcmC0D0p:0: pos=79209/44100/88200, hwptr=0/49118409/49118409/49039200 [ 1401.961710] hwptr_update: pcmC0D0p:0: pos=79210/44100/88200, hwptr=1/49118409/49118410/49039200 [ 1401.961718] hwptr_update: pcmC0D0p:0: pos=79211/44100/88200, hwptr=1/49118410/49118411/49039200 [ 1401.962002] hwptr_update: pcmC0D0p:0: pos=79222/44100/88200, hwptr=11/49118411/49118422/49039200 [ 1401.962008] hwptr_update: pcmC0D0p:0: pos=79223/44100/88200, hwptr=1/49118422/49118423/49039200 [ 1401.962032] hwptr_update: pcmC0D0p:0: pos=79224/44100/88200, hwptr=1/49118423/49118424/49039200 [ 1401.962037] hwptr_update: pcmC0D0p:0: pos=79224/44100/88200, hwptr=0/49118424/49118424/49039200 [ 1401.962251] hwptr_update: pcmC0D0p:0: pos=79233/44100/88200, hwptr=9/49118424/49118433/49039200 [ 1401.962260] hwptr_update: pcmC0D0p:0: pos=79234/44100/88200, hwptr=1/49118433/49118434/49039200 [ 1401.962282] hwptr_update: pcmC0D0p:0: pos=79235/44100/88200, hwptr=1/49118434/49118435/49039200 [ 1401.962290] hwptr_update: pcmC0D0p:0: pos=79235/44100/88200, hwptr=0/49118435/49118435/49039200 [ 1401.962494] hwptr_update: pcmC0D0p:0: pos=79245/44100/88200, hwptr=10/49118435/49118445/49039200 [ 1401.962503] hwptr_update: pcmC0D0p:0: pos=79245/44100/88200, hwptr=0/49118445/49118445/49039200 [ 1401.962525] hwptr_update: pcmC0D0p:0: pos=79246/44100/88200, hwptr=1/49118445/49118446/49039200 [ 1401.962532] hwptr_update: pcmC0D0p:0: pos=79246/44100/88200, hwptr=0/49118446/49118446/49039200 [ 1401.962737] hwptr_update: pcmC0D0p:0: pos=79256/44100/88200, hwptr=10/49118446/49118456/49039200 [ 1401.962746] hwptr_update: pcmC0D0p:0: pos=79256/44100/88200, hwptr=0/49118456/49118456/49039200 [ 1401.962788] hwptr_update: pcmC0D0p:0: pos=79257/44100/88200, hwptr=1/49118456/49118457/49039200 [ 1401.962799] hwptr_update: pcmC0D0p:0: pos=79258/44100/88200, hwptr=1/49118457/49118458/49039200 [ 1401.963124] hwptr_update: pcmC0D0p:0: pos=79272/44100/88200, hwptr=14/49118458/49118472/49039200 [ 1401.963136] hwptr_update: pcmC0D0p:0: pos=79273/44100/88200, hwptr=1/49118472/49118473/49039200 [ 1401.963162] hwptr_update: pcmC0D0p:0: pos=79274/44100/88200, hwptr=1/49118473/49118474/49039200 [ 1401.963172] hwptr_update: pcmC0D0p:0: pos=79274/44100/88200, hwptr=0/49118474/49118474/49039200 [ 1401.963450] hwptr_update: pcmC0D0p:0: pos=79287/44100/88200, hwptr=13/49118474/49118487/49039200 [ 1401.963458] hwptr_update: pcmC0D0p:0: pos=79287/44100/88200, hwptr=0/49118487/49118487/49039200 [ 1401.963485] hwptr_update: pcmC0D0p:0: pos=79288/44100/88200, hwptr=1/49118487/49118488/49039200 [ 1401.963491] hwptr_update: pcmC0D0p:0: pos=79289/44100/88200, hwptr=1/49118488/49118489/49039200 [ 1401.963695] hwptr_update: pcmC0D0p:0: pos=79298/44100/88200, hwptr=9/49118489/49118498/49039200 [ 1401.963704] hwptr_update: pcmC0D0p:0: pos=79298/44100/88200, hwptr=0/49118498/49118498/49039200 [ 1401.963729] hwptr_update: pcmC0D0p:0: pos=79299/44100/88200, hwptr=1/49118498/49118499/49039200 [ 1401.963737] hwptr_update: pcmC0D0p:0: pos=79300/44100/88200, hwptr=1/49118499/49118500/49039200 [ 1401.964087] hwptr_update: pcmC0D0p:0: pos=79314/44100/88200, hwptr=14/49118500/49118514/49039200 [ 1401.964099] hwptr_update: pcmC0D0p:0: pos=79315/44100/88200, hwptr=1/49118514/49118515/49039200 [ 1401.964120] hwptr_update: pcmC0D0p:0: pos=79316/44100/88200, hwptr=1/49118515/49118516/49039200 [ 1401.964127] hwptr_update: pcmC0D0p:0: pos=79316/44100/88200, hwptr=0/49118516/49118516/49039200 [ 1402.148779] hwptr_update: pcmC0D0p:0: pos=87452/44100/88200, hwptr=8136/49118516/49126652/49039200 [ 1402.148863] hwptr_update: pcmC1D7p:0: pos=3896/44096/88192, hwptr=8367/49118473/49126840/49034752 [ 1402.149459] hwptr_update: pcmC0D0p:0: pos=87481/44100/88200, hwptr=29/49126652/49126681/49039200 [ 1402.149468] hwptr_update: pcmC0D0p:0: pos=87482/44100/88200, hwptr=1/49126681/49126682/49039200 [ 1402.149480] hwptr_update: pcmC0D0p:0: pos=87482/44100/88200, hwptr=0/49126682/49126682/49039200 [ 1402.149489] hwptr_update: pcmC1D7p:0: pos=3925/44096/88192, hwptr=29/49126840/49126869/49122944 [ 1402.149499] hwptr_update: pcmC1D7p:0: pos=3925/44096/88192, hwptr=0/49126869/49126869/49122944 [ 1402.339048] hwptr_update: pcmC0D0p:0: pos=7633/44100/88200, hwptr=8351/49126682/49135033/49039200 [ 1402.339063] hwptr_update: pcmC1D7p:0: pos=12276/44096/88192, hwptr=8351/49126869/49135220/49122944 [ 1402.339657] hwptr_update: pcmC0D0p:0: pos=7661/44100/88200, hwptr=28/49135033/49135061/49127400 [ 1402.339667] hwptr_update: pcmC0D0p:0: pos=7661/44100/88200, hwptr=0/49135061/49135061/49127400 [ 1402.339677] hwptr_update: pcmC1D7p:0: pos=12303/44096/88192, hwptr=27/49135220/49135247/49122944 [ 1402.339687] hwptr_update: pcmC1D7p:0: pos=12304/44096/88192, hwptr=1/49135247/49135248/49122944 [ 1402.339691] hwptr_update: pcmC0D0p:0: pos=7662/44100/88200, hwptr=1/49135061/49135062/49127400 [ 1402.529286] hwptr_update: pcmC0D0p:0: pos=16015/44100/88200, hwptr=8353/49135062/49143415/49127400 [ 1402.529298] hwptr_update: pcmC1D7p:0: pos=20657/44096/88192, hwptr=8353/49135248/49143601/49122944 [ 1402.530452] hwptr_update: pcmC1D7p:0: pos=20707/44096/88192, hwptr=50/49143601/49143651/49122944 [ 1402.530455] hwptr_update: pcmC0D0p:0: pos=16067/44100/88200, hwptr=52/49143415/49143467/49127400 [ 1402.530473] hwptr_update: pcmC0D0p:0: pos=16067/44100/88200, hwptr=0/49143467/49143467/49127400 [ 1402.530477] hwptr_update: pcmC1D7p:0: pos=20709/44096/88192, hwptr=2/49143651/49143653/49122944 [ 1402.719593] hwptr_update: pcmC0D0p:0: pos=24399/44100/88200, hwptr=8332/49143467/49151799/49127400 [ 1402.719597] hwptr_update: pcmC1D7p:0: pos=29040/44096/88192, hwptr=8331/49143653/49151984/49122944 [ 1402.721222] hwptr_update: pcmC1D7p:0: pos=29112/44096/88192, hwptr=72/49151984/49152056/49122944 [ 1402.721226] hwptr_update: pcmC0D0p:0: pos=24471/44100/88200, hwptr=72/49151799/49151871/49127400 [ 1402.721246] hwptr_update: pcmC0D0p:0: pos=24471/44100/88200, hwptr=0/49151871/49151871/49127400 [ 1402.721249] hwptr_update: pcmC1D7p:0: pos=29113/44096/88192, hwptr=1/49152056/49152057/49122944 [ 1402.909914] hwptr_update: pcmC0D0p:0: pos=32783/44100/88200, hwptr=8312/49151871/49160183/49127400 [ 1402.909918] hwptr_update: pcmC1D7p:0: pos=37425/44096/88192, hwptr=8312/49152057/49160369/49122944 [ 1402.911092] hwptr_update: pcmC1D7p:0: pos=37477/44096/88192, hwptr=52/49160369/49160421/49122944 [ 1402.911095] hwptr_update: pcmC0D0p:0: pos=32836/44100/88200, hwptr=53/49160183/49160236/49127400 [ 1402.911114] hwptr_update: pcmC0D0p:0: pos=32837/44100/88200, hwptr=1/49160236/49160237/49127400 [ 1402.911117] hwptr_update: pcmC1D7p:0: pos=37478/44096/88192, hwptr=1/49160421/49160422/49122944 [ 1403.100160] hwptr_update: pcmC0D0p:0: pos=41165/44100/88200, hwptr=8328/49160237/49168565/49127400 [ 1403.100169] hwptr_update: pcmC1D7p:0: pos=45807/44096/88192, hwptr=8329/49160422/49168751/49122944 [ 1403.101303] hwptr_update: pcmC1D7p:0: pos=45857/44096/88192, hwptr=50/49168751/49168801/49122944 [ 1403.101307] hwptr_update: pcmC0D0p:0: pos=41216/44100/88200, hwptr=51/49168565/49168616/49127400 [ 1403.101326] hwptr_update: pcmC0D0p:0: pos=41217/44100/88200, hwptr=1/49168616/49168617/49127400 [ 1403.101330] hwptr_update: pcmC1D7p:0: pos=45858/44096/88192, hwptr=1/49168801/49168802/49122944 [ 1403.290423] hwptr_update: pcmC0D0p:0: pos=49547/44100/88200, hwptr=8330/49168617/49176947/49127400 [ 1403.290425] hwptr_update: pcmC1D7p:0: pos=54189/44096/88192, hwptr=8331/49168802/49177133/49122944 [ 1403.290996] hwptr_update: pcmC1D7p:0: pos=54214/44096/88192, hwptr=25/49177133/49177158/49122944 [ 1403.291002] hwptr_update: pcmC0D0p:0: pos=49573/44100/88200, hwptr=26/49176947/49176973/49127400 [ 1403.291014] hwptr_update: pcmC1D7p:0: pos=54215/44096/88192, hwptr=1/49177158/49177159/49122944 [ 1403.291016] hwptr_update: pcmC0D0p:0: pos=49573/44100/88200, hwptr=0/49176973/49176973/49127400 [ 1403.480689] hwptr_update: pcmC0D0p:0: pos=57930/44100/88200, hwptr=8357/49176973/49185330/49127400 [ 1403.480694] hwptr_update: pcmC1D7p:0: pos=62571/44096/88192, hwptr=8356/49177159/49185515/49122944 [ 1403.482071] hwptr_update: pcmC1D7p:0: pos=62632/44096/88192, hwptr=61/49185515/49185576/49122944 [ 1403.482075] hwptr_update: pcmC0D0p:0: pos=57991/44100/88200, hwptr=61/49185330/49185391/49127400 [ 1403.482095] hwptr_update: pcmC0D0p:0: pos=57992/44100/88200, hwptr=1/49185391/49185392/49127400 [ 1403.482099] hwptr_update: pcmC1D7p:0: pos=62634/44096/88192, hwptr=2/49185576/49185578/49122944 [ 1403.671010] hwptr_update: pcmC0D0p:0: pos=66314/44100/88200, hwptr=8322/49185392/49193714/49127400 [ 1403.671014] hwptr_update: pcmC1D7p:0: pos=70956/44096/88192, hwptr=8322/49185578/49193900/49122944 [ 1403.672485] hwptr_update: pcmC1D7p:0: pos=71021/44096/88192, hwptr=65/49193900/49193965/49122944 [ 1403.672498] hwptr_update: pcmC0D0p:0: pos=66380/44100/88200, hwptr=66/49193714/49193780/49127400 [ 1403.672514] hwptr_update: pcmC0D0p:0: pos=66381/44100/88200, hwptr=1/49193780/49193781/49127400 [ 1403.672518] hwptr_update: pcmC1D7p:0: pos=71023/44096/88192, hwptr=2/49193965/49193967/49122944 [ 1403.861327] hwptr_update: pcmC0D0p:0: pos=74699/44100/88200, hwptr=8318/49193781/49202099/49127400 [ 1403.861330] hwptr_update: pcmC1D7p:0: pos=79340/44096/88192, hwptr=8317/49193967/49202284/49122944 [ 1403.862567] hwptr_update: pcmC1D7p:0: pos=79395/44096/88192, hwptr=55/49202284/49202339/49122944 [ 1403.862572] hwptr_update: pcmC0D0p:0: pos=74755/44100/88200, hwptr=56/49202099/49202155/49127400 [ 1403.862590] hwptr_update: pcmC0D0p:0: pos=74755/44100/88200, hwptr=0/49202155/49202155/49127400 [ 1403.862593] hwptr_update: pcmC1D7p:0: pos=79396/44096/88192, hwptr=1/49202339/49202340/49122944 [ 1404.051599] hwptr_update: pcmC0D0p:0: pos=83081/44100/88200, hwptr=8326/49202155/49210481/49127400 [ 1404.051603] hwptr_update: pcmC1D7p:0: pos=87723/44096/88192, hwptr=8327/49202340/49210667/49122944 [ 1404.053086] hwptr_update: pcmC0D0p:0: pos=83147/44100/88200, hwptr=66/49210481/49210547/49127400 [ 1404.053090] hwptr_update: pcmC1D7p:0: pos=87789/44096/88192, hwptr=66/49210667/49210733/49122944 [ 1404.053112] hwptr_update: pcmC1D7p:0: pos=87790/44096/88192, hwptr=1/49210733/49210734/49122944 [ 1404.053115] hwptr_update: pcmC0D0p:0: pos=83148/44100/88200, hwptr=1/49210547/49210548/49127400 [ 1404.241897] hwptr_update: pcmC0D0p:0: pos=3266/44100/88200, hwptr=8318/49210548/49218866/49127400 [ 1404.241902] hwptr_update: pcmC1D7p:0: pos=7914/44096/88192, hwptr=8316/49210734/49219050/49122944 [ 1404.243483] hwptr_update: pcmC1D7p:0: pos=7985/44096/88192, hwptr=71/49219050/49219121/49211136 [ 1404.243488] hwptr_update: pcmC0D0p:0: pos=3336/44100/88200, hwptr=70/49218866/49218936/49215600 [ 1404.243508] hwptr_update: pcmC0D0p:0: pos=3336/44100/88200, hwptr=0/49218936/49218936/49215600 [ 1404.243512] hwptr_update: pcmC1D7p:0: pos=7986/44096/88192, hwptr=1/49219121/49219122/49211136 regards, Kontr-Olli (In reply to comment #15) so...looks like not synced, but not sure...Problem seems what you already mentioned earlier...due to different period-sizes of Nvidia and Intel card... but I don't understand, why everything runs smooth as soon as the pluse audio-mixer is running in foreground?! do you have an idea how to manage equal spaced periods in pulse in order to verify that this causes the problem... Thanks... Kontr-Olli it is hard to tell but I expect the number of call in the log are the same for two devices is there any option to force the sound card using the same period size and buffer size ? your hdmi device have no volume control but you analog device have hardware volume control. do the volume slider really control volume of both devices ? the time to perform software volume calculation may be different is there any option to ignore the hardware volume and force both cards using software volume ? (In reply to comment #17) > is there any option to force the sound card using the same period size and > buffer size ? I don't know...in pure alsa one can do this in the .asoundrc config-file....but I think for pulse this has to be done directly via pulse-config...but I haven't found anything like this for pulse... > your hdmi device have no volume control but you analog device have hardware > volume control. > > do the volume slider really control volume of both devices ? yes, I've just added the HDMI and analog device as simultanious output via "paprefs" tool....and then in "pavucontrol" I have choosen to combine the analog with the HDMI port 2 to a new virtual device...so, in pavucontrol I have then three devices, analog, HDMI and the simulanious one....when I control the volume of the simultanious device both combined devices change their volume.... > the time to perform software volume calculation may be different > > is there any option to ignore the hardware volume and force both cards using > software volume ? I don't know...for me it looks like both devices uses already the software-volume control, cause they are controlled combined by the virtual simultanious one... regards, Oliver ( 40.383| 3.672) D: [pulseaudio] module-combine-sink.c: [alsa_output.pci-0000_01_00.1.hdmi-stereo] total=199.42ms sink=199.42ms ( 40.383| 0.000) D: [pulseaudio] module-combine-sink.c: [alsa_output.pci-0000_00_1b.0.analog-stereo] total=199.75ms sink=199.32ms ( 40.383| 0.000) I: [pulseaudio] module-combine-sink.c: [combined] avg total latency is 199.58 msec. ( 40.383| 0.000) I: [pulseaudio] module-combine-sink.c: [combined] target latency is 199.42 msec. ( 40.383| 0.000) I: [pulseaudio] module-combine-sink.c: [alsa_output.pci-0000_01_00.1.hdmi-stereo] new rate is 44100 Hz; ratio is 1.000; latency is 199.42 msec. ( 40.383| 0.000) I: [pulseaudio] module-combine-sink.c: [alsa_output.pci-0000_00_1b.0.analog-stereo] new rate is 44100 Hz; ratio is 1.000; latency is 199.75 msec. are there any method to force them to use the same period and buffer size ? https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation/sound/alsa/ALSA-Configuration.txt align_buffer_size - Force rounding of buffer/period sizes to multiples of 128 bytes. This is more efficient in terms of memory access but isn't required by the HDA spec and prevents users from specifying exact period/buffer sizes. (default = on) Created attachment 96555 [details] [review] possible patch The reason is that combine-sink does not honour the client latency requests and this leaves some clients unhappy. Starting pavucontrol starts the monitor devices that reconfigure each sink directly into low-latency mode, which then makes the clients of combine-sinks happy again. Hi Wim, thanks for the patch...I've integrated it into my gentoo ebuild tree for pulseaudio 5.0... so far the "stuttering" is gone while playing flash videos in chrome, but a new problem occurs....now the two sinks aren't synchronous anymore! If someone speaks in the flash video, it first comes out of the HDMI sink and a few miliseconds later it is played on the second analogue sink... Do you have an idea how to fix this? with kind regards, Oliver Hi, a second test reveales again stuttering....even worse than before....after this i reloaded the flash-site....and sound wasn't synchronous anymore... starting pulse-audio mixer before playing video solves again the problems.. regards, Oliver Created attachment 96704 [details] [review] Improved patch This is an updated patch that keeps the streams in sync. Thanks for the patch! Here's some feedback: You may not call pa_sink_input_set_requested_latency_within_thread() from sink_update_requested_latency(), because the former must be called from the sink input's thread, but the latter is called from the combine sink's thread. I think there needs to be a new message that is sent to the sink inputs with pa_asyncmsgq_post() when the combine sink's requested latency changes. When creating new outputs, the hard-coded BLOCK_USEC value is used as the initial requested latency for sink inputs, but we should use the combine sink's current requested latency instead. I don't understand what benefit there is for lowering BLOCK_USEC down to 20 ms. The stated reason is to help low latency applications, but if the applications want low latency, they should request low latency, and thanks to this patch, that should result in low latency (as long as the underlying sinks support that). You should set the PA_SINK_DYNAMIC_LATENCY flag for the combine sink now that dynamic latency has been implemented. I would prefer to have the added debug messages in the core, instead of (potentially) duplicating the same message in multiple modules. Hi, thanks for the new patch and the comments... I've tested the improved patch....but changed as suggested by Tanu the 20ms back to 200ms... now the sinks are sync again, but are still/again stuttering...I would guess if I change to 20ms flash streams are fine?! So does flash-player in chrome "request" low latency? And if so, the 200ms for initialization should be fine, right? regards, Oliver Hi, I've tested a second run with pulse-mixer active => everthing works fine... after closing the mixer, the sound is async again... so at the moment it looks like this: reinstalled pulse 5.0 with improved patch => reboot => opened chrome with flash video => sound is stuttering => opened pulse-mixer => reload flash-video in chrome => sound is fine => closed pulse-mixer => reload flash video in chrome => sound is async => reload flash video in chrome => sound is stuttering so, now, sometimes the sound is async or stuttering....sometimes even both...playing flash with pulse-mixer opened again solves all issues... regards, Oliver Created attachment 96765 [details] [review] Improved patch This new attempt makes the sink support DYNAMIC_LATENCY and other suggestions from Comment 26. Hi... great...works like a charme....no problems anymore !! Thank you very much. I will test this patch for a period of time, but at the moment everthing is alright. regards, Oliver Thanks for testing, Oliver. Thanks for the patch again! It's starting to be pretty complicated to review, but I got through it anyway. Comments: Apparently the logic for setting the output requested latency is to forward the combine sink requested latency, except when that is -1, in which case the maximum of the requested latencies of the downstream sinks is used. I think the code is a bit broken if it does try to implement this (there's at least the issue that if any of the downstream sinks has requested latency of -1, that will propagate to all outputs, and sink_update_requested_latency() doesn't handle transitions to -1 correctly), but actually I think this whole logic is unnecessarily complicated. I think it's sufficient to just directly forward the requested latency of the combine sink to the outputs. If you think -1 needs to be handled specially, please explain why. If the requested latency logic is simplified as I suggest, then I think the userdata->requested_latency and output->requested_latency struct fields can be removed. update_latency_range() doesn't handle correctly the case where there are no outputs, leading to crash in pa_sink_set_latency_range_within_thread(). I think it would be best to set both the max and min latencies to u->block_usec in this case. You should call pa_sink_set_latency_range() before calling pa_sink_put() to ensure that the initial latency range is sane. The latency values should be the same that you use in update_latency_range() when there are no outputs. SINK_MESSAGE_UPDATE_MAX_REQUEST and SINK_MESSAGE_UPDATE_LATENCY_RANGE should be sent also from sink_input_detach_cb(). Then there's this issue that was there already before: SINK_MESSAGE_ADD_OUTPUT is sent to the combine sink thread before the output has been attached. After ADD_OUTPUT, the combine sink thread will start accessing the output parameters, but the output parameters are not valid before attaching. Fixing this should probably be done in a separate patch, and maybe this is something that is out of scope for this bug, so you could ignore this. I have added a todo item for myself to fix this. It would be nice to get the next version also on the mailing list for easier commenting. Created attachment 97405 [details] [review] Improved patch Here is an updated patch that I hope addresses the issues in Comment #32 All of the update_requested_latency logic is removed and essentially replaced by update_latency_range. I did SINK_MESSAGE_UPDATE_MAX_REQUEST and SINK_MESSAGE_UPDATE_LATENCY_RANGE from the disable_output. Doing this from sink_input_detach_cb() would not work because the output is still in the list of outputs at that stage. Hi, I'm currently doing some tests with the new and improved patch....works very well...thanks to all contributions! regards, Oliver Hi, I'm currently doing some tests with the new and improved patch....works very well...thanks to all contributions! regards, Oliver Hi, I've recognized a problem with the improved patch....as soon as I hear music from qmmp and start a audio stream from sound-cloud pulseaudio crashes... I will check with the unmodified version of pulse to see if it is related to the new patch.. regards, Oliver it's great to see all this progress, thanks for working on it! are there Amy minimum hardware requirement of combine sinks ? do pulseaudio intend to support combine sink of local and network sink which does not support same rate (e.g, one only support 44100 and the other only support 48000 )? Hi, I have several problems with the "new" improved patch...the old one worked quite stable, with new improved one pulseaudio often crashes. I have to start pulse again by "pulseaudio --start" to get it running afterwards, but unfortunately the analog output isn't listed and played anymore... mostly observed when playing flash video streams... If you need further informations, like debug informations please let me know....especially, please give me a hint how to log these information to be able to post here... kind regards, Oliver When having crashes, getting a backtrace (a.k.a. stack trace) with gdb is helpful. If you don't know how to get a backtrace, there are some instructions here: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Community/ (In reply to comment #38) > are there Amy minimum hardware requirement of combine sinks ? > > do pulseaudio intend to support combine sink of local and network sink which > does not support same rate (e.g, one only support 44100 and the other only > support 48000 )? The combine sink works with any device. Resampling is used as necessary. 3.6.1 DMA Position in Current Buffer The “DMA Position in Buffer” structure is written to a memory buffer each time a stream DMA position changes. 3.6.2 Buffer Descriptor List The Buffer Descriptor List (BDL) is a memory structure that describes the buffers in memory. The BDL is comprised of a series of Buffer Descriptor List Entries. There must be at least two entries in the list, with a maximum of 256 entries 3.6.3 Buffer Descriptor List Entry Each Buffer Descriptor List Entry (BDLE) contains a description of a buffer which is a piece of the whole cyclic stream buffer. The buffers described by the BDLE must start on a 128-byte boundary, and the length must be an integer number of Words. your two hda controllers will use same buffer size(buffer time 1 seconds) at stereo 48000Hz since One second * 48000Hz * 4 bytes align at 128 byte boundary but 44100Hz does not align at 128bytes Fix applied: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=23f120aabbf4d48d7012e196cf95d89ec6b6d8c8 Oliver, if you still see crashes, please let me know (and backtraces would be nice). |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.