PulseAudio - Connecting the fridge

Granted the fridge has audio components of course...

Now, once we have our audio bus on Jack's shoulders, we can read more good ideas on how to live in this changing world.

First of all let us stipulate - we're not talking about replacing jack with pulse - they are from different worlds. We're to get the best from both worlds for our home entertainment.

To get a clue what are we going to do - read this nice article on jack wiki - rather second part - pulse2jack. To get a clue why do we I need this... In fact it is simple - I want to utilize my BT dongle for something more than just remote - to stream music through A2DP from my mp3 player or phone.

Despite (still) existing pcm bluetooth plugin - it's phasing out, and pulseaudio seems is going to be the only audio-endpoint utilizing Media API of BlueZ (proof,another).

Note: if you're getting nasty messages while starting pulse server, saying somehting like:
JACK error >Cannot use real-time scheduling (RR/5)
and want to get rid of them you might want to disable realtime on pulse - its ROUNDROBIN realtime scheduleing is not compatible with Jack's FIFO sheduling and causes this error.

[ruff@mo ~]$ ps -Leo pid,tid,user,cls,ni,rtprio,pri,args | grep jack
 7854  7854 ruff      TS   0      -  19 /usr/bin/jackdbus auto
 7854  7870 ruff      TS   0      -  19 /usr/bin/jackdbus auto
 7854  7871 ruff      FF   -     10  50 /usr/bin/jackdbus auto
 7854  7872 ruff      TS   0      -  19 /usr/bin/jackdbus auto

[ruff@mo ~]$ pulseaudio --realtime
W: [pulseaudio] module-jack-sink.c: JACK error >Cannot use real-time scheduling
(RR/5)(1: Die Operation ist nicht erlaubt)<
W: [pulseaudio] module-jack-sink.c: JACK error >JackClient::AcquireSelfRealTime
error<

[ruff@mo ~]$ ps -Leo pid,tid,user,cls,ni,rtprio,pri,args | grep pulse
15087 15087 ruff      TS -11      -  30 pulseaudio --realtime
15087 15088 ruff      RR   -      9  49 pulseaudio --realtime
15087 15089 ruff      RR   -      9  49 pulseaudio --realtime
15087 15090 ruff      RR   -      5  45 pulseaudio --realtime
15087 15091 ruff      RR   -      9  49 pulseaudio --realtime
15087 15092 ruff      RR   -      9  49 pulseaudio --realtime
15087 15093 ruff      RR   -      5  45 pulseaudio --realtime
15087 15094 ruff      RR   -      9  49 pulseaudio --realtime

[ruff@mo ~]$ pulseaudio 

[ruff@mo ~]$ ps -Leo pid,tid,user,cls,ni,rtprio,pri,args | grep pulse
15115 15115 ruff      TS -11      -  30 pulseaudio
15115 15116 ruff      TS -11      -  30 pulseaudio
15115 15117 ruff      TS -11      -  30 pulseaudio
15115 15118 ruff      TS -11      -  30 pulseaudio
15115 15119 ruff      FF   -      5  45 pulseaudio
15115 15120 ruff      TS -11      -  30 pulseaudio
15115 15121 ruff      TS -11      -  30 pulseaudio
15115 15122 ruff      FF   -      5  45 pulseaudio

Here we see that Jack is running FIFO and needs similar scheduling for clients. These two FF pulse threads in the last output are our jack input/sink clients. On the other hand output shows that even with the message threads are still having rtprio RR/5 and if you go look in jack you see them there anyway. I cannot provide any recommendation at this moment - whether to keep it RR or to run non-RR pulse.

Alas - after all this we have consumer level audiobus(dynamic, discoverable, plugNplay), connected to the professional level (low latency, time-syncronized) audiobus, with several static duplex alsa endpoints. So we are fully charged to connect whatever we want with whatever parameters we need.