After playing around with this for about 6 hours, I found some interesting 
data.  The latency on the g722 (since renamed to ip_mcast) null-sink hovers 
around 20mS when I have pavucontrol running, and around 600mS when I don’t have 
it running.  Since G722 requires pretty consistent 20Ms packets, this is 
certainly the problem.  The max request size is also obviously different.  Is 
it possible to adjust the max request size?  That is the only thin gI can think 
of that would really impact the latency here.

Thanks again,
Travis

Good:
    index: 2
        name: <ip_mcast>
        driver: <module-null-sink.c>
        flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
        state: IDLE
        suspend cause:
        priority: 1000
        volume: mono: 65536 / 100% / 0.00 dB
                balance 0.00
        base volume: 65536 / 100% / 0.00 dB
        volume steps: 65537
        muted: no
        current latency: 20.63 ms
        max request: 1 KiB
        max rewind: 1 KiB
        monitor source: 3
        sample spec: s16le 1ch 16000Hz
        channel map: mono
                     Mono
        used by: 0
        linked by: 1
        configured latency: 40.00 ms; range is 0.50 .. 2000.00 ms
        module: 4
        properties:
                device.description = "ip_mcast"
                device.class = "abstract"
                device.icon_name = "audio-card”

Bad:
  index: 2
        name: <ip_mcast>
        driver: <module-null-sink.c>
        flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
        state: IDLE
        suspend cause:
        priority: 1000
        volume: mono: 65536 / 100% / 0.00 dB
                balance 0.00
        base volume: 65536 / 100% / 0.00 dB
        volume steps: 65537
        muted: no
        current latency: 657.77 ms
        max request: 62 KiB
        max rewind: 62 KiB
        monitor source: 3
        sample spec: s16le 1ch 16000Hz
        channel map: mono
                     Mono
        used by: 0
        linked by: 0
        configured latency: 2000.00 ms; range is 0.50 .. 2000.00 ms
        module: 4
        properties:
                device.description = "ip_mcast"
                device.class = "abstract"
                device.icon_name = "audio-card"


> On Oct 24, 2018, at 11:06, Travis Brown <tra...@bryx.com> wrote:
> 
> Hi,
> 
>   I am using Pulseaudio to send data from an application to 3 different 
> outputs simultaneously: HDMI, analog output and a G.722 RTP stream.   To 
> accomplish this, I set up a null sink call g722 using the following setting 
> in be default.pa:
> 
>     load-module module-null-sink sink_name=g722 
> sink_properties=device.description=“g722”
>     load-module module-combine-sink sink_name=combined 
> slaves=alsa_output.pci-0000_00_03.0.hdmi-stereo-extra1,alsa_output.pci-0000_00_1b.0.analog-stereo,g722
> 
>  It actually works pretty great.  I use ffmpeg to pull data from the g722 
> monitor and transcode it and send it out via multicast to the 
> phones/speakers.  
> 
>     /usr/bin/ffmpeg -re -f pulse -i g722.monitor -filter_complex 
> aresample=16000,asetnsamples=n=160 -vn -ac 1 -acodec g722 -f rtp 
> udp://224.0.2.60:50000 <udp://224.0.2.60:50000>
> 
>  The issue I am having is that ffmpeg underruns most of the time UNTIL I 
> start pavucontrol.  Starting pavucontrol makes things behave beautifully.  
> ffmpeg gets a constant stream of data and the audio sounds great.  What I 
> cannot figure out is what pavucontrol is doing to make things better.  It 
> must be setting up something for the VU meters, but I am not sure that would 
> actually improve things, or why it would.  
> 
> Thanks,
> Travis
> 

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to