| 1 |
On Saturday, 1 October 2022 18:11:19 BST Wol wrote: |
| 2 |
> On 01/10/2022 17:56, Michael wrote: |
| 3 |
> > Anyway, I ventured into pipewire because I wanted to see if Skype would |
| 4 |
> > work without pulseaudio and in this system it won't. After I manually |
| 5 |
> > installed pipewire Skype won't access the microphone. 🙁 |
| 6 |
> |
| 7 |
> I've got some vague feeling that pipewire is designed to happily sit |
| 8 |
> under pulseaudio. The design aim was to replace both Jack and pulseaudio |
| 9 |
> but it basically just presents a sound device to the layers above, so |
| 10 |
> just like you can stack block devices for disk access, you can stack |
| 11 |
> jack, pulseaudio and pipewire for sound. |
| 12 |
> |
| 13 |
> The big difference between a sound stack and a block stack is that a |
| 14 |
> block stack is asynchronous and latency is (relatively) unimportant. In |
| 15 |
> a sound stack some applications *demand* synchronicity, and latency is |
| 16 |
> everything. Jack is extremely latency sensitive, pulseaudio buffers and |
| 17 |
> doesn't care, and pipewire is intended to satisfy both. |
| 18 |
> |
| 19 |
> So the intent was clearly to install pipewire underneath a working |
| 20 |
> pulseaudio, and just move applications across as and when. |
| 21 |
> |
| 22 |
> Cheers, |
| 23 |
> Wol |
| 24 |
|
| 25 |
My very limited understanding is pipewire is meant to replace pulseaudio and |
| 26 |
jack, rather than become part of an audio/video stack: |
| 27 |
|
| 28 |
https://docs.pipewire.org/page_overview.html |
| 29 |
|
| 30 |
I think applications will gradually be coded to work with pipewire, until then |
| 31 |
suitable pipewire plugins would be required. Perhaps for Skype to work today |
| 32 |
I will also have to enable pulseaudio, at which point it will not need |
| 33 |
pipewire itself. The strange thing is audio playback works great with |
| 34 |
pipewire, it's the microphone which does not appear to be capturing anything |
| 35 |
and causes Skype to disconnect. :-/ |
Archives