github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #281] [feature request] Share audio device #226

New issue

Closed

opened 2026-05-05 05:44:02 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 05:44:02 -06:00

Owner

Originally created by @imanolGOMI on GitHub (Apr 5, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/281

I have listen that is possible share audio and microphone. I want use my mic and my headsphones

I would like to use my microphone and my headphones (like the mouse and keyboard) on one computer and when I change the other that works on the other.

I'm sorry if this is stupid, I do not want to waste your time :)

Originally created by @imanolGOMI on GitHub (Apr 5, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/281 I have listen that is possible share audio and microphone. I want use my mic and my headsphones I would like to use my microphone and my headphones (like the mouse and keyboard) on one computer and when I change the other that works on the other. I'm sorry if this is stupid, I do not want to waste your time :)

gitea-mirror closed this issue

2026-05-05 05:44:05 -06:00

gitea-mirror commented

2026-05-05 05:44:09 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 5, 2019):

At least for linux, this already exists (at least, for outputs to my knowledge) via a pulseaudio module.

I feel like this would be better suited as it's own application.

@AdrianKoshka commented on GitHub (Apr 5, 2019): At least for linux, this already exists (at least, for outputs to my knowledge) via a pulseaudio module. I feel like this would be better suited as it's own application.

gitea-mirror commented

2026-05-05 05:44:10 -06:00

Author

Owner

@mpictor commented on GitHub (Apr 28, 2019):

A few links for those who wonder how it can be done, particularly between windows and linux (note, I haven't yet tried any of these):

first some relevant stack exchange questions: superuser 1 superuser 2 sound.stackexchange

... and some solutions (not tested by me, as noted above):

win7 apparently has a Play To feature that can broadcast to things supporting DLNA
pulseaudio apparently can be built for windows, or at least could in the XP era. It's unclear to me whether this works with anything newer.
edcast/altacast + icecast (though edcast/altacast appear to be outdated - screenshots from winxp, at best)

I feel like this would be better suited as it's own application.

@AdrianKoshka sure, though Barrier could make this less painful by documenting what's needed and/or helping the user configure it. :)

@mpictor commented on GitHub (Apr 28, 2019): A few links for those who wonder how it can be done, particularly between windows and linux (note, I haven't _yet_ tried any of these): first some relevant stack exchange questions: [superuser 1](https://superuser.com/questions/553277/share-audio-between-computers-over-network-like-mouse-without-borders) [superuser 2](https://superuser.com/questions/29844/play-audio-over-network-with-windows-7) [sound.stackexchange](https://sound.stackexchange.com/questions/22921/stream-windows-audio-over-the-network) ... and some solutions (not tested by me, as noted above): * win7 apparently has a `Play To` feature that can broadcast to things supporting DLNA * pulseaudio apparently can be built for windows, or at least could in the XP era. It's unclear to me whether this works with anything newer. * edcast/altacast + icecast (though edcast/altacast appear to be outdated - screenshots from winxp, at best) ---- > I feel like this would be better suited as it's own application. @AdrianKoshka sure, though Barrier could make this less painful by documenting what's needed and/or helping the user configure it. :)

gitea-mirror commented

2026-05-05 05:44:13 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Aug 23, 2019):

Upon reflection, I still feel this is incredibly out of scope for barrier and would only add unneeded complexity.

@AdrianKoshka commented on GitHub (Aug 23, 2019): Upon reflection, I still feel this is incredibly out of scope for barrier and would only add unneeded complexity.

gitea-mirror commented

2026-05-05 05:44:16 -06:00

Author

Owner

@Vigrond commented on GitHub (Nov 15, 2020):

Just wanted to add a method that worked for me with barrier using ffmpeg. This will share desktop audio only (not microphone input).

In this example, the client is Ubuntu, and the server is Windows. ffmpeg will need to be installed on both. Other scenarios will need a different command and understanding of ffmpeg.

On the "client", run the ffmpeg command:

ffmpeg -re -f alsa -ac 2 -i default -f rtp rtp://server:1234

Where server is your barrier server IP address. This will stream desktop audio to the specified address

(If you use pulse instead of alsa, replace -f alsa with -f pulse )

It will output something like:

SDP:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.1.82
t=0 0
a=tool:libavformat 58.21.100
m=audio 1234 RTP/AVP 97
b=AS:768
a=rtpmap:97 PCMU/48000/2

In my example the server is 192.168.1.82

On the server machine (192.168.1.82), copy the SDP text above into a file sdp_file and run the ffplay command:

./ffplay -protocol_whitelist 'rtp,file,udp' .\sdp_file

Enjoy streamed low-latency audio.

I could see this potentially working inside barrier in the future, so here's a little inspiration and direction in case anyone has time for a fork.

@Vigrond commented on GitHub (Nov 15, 2020): Just wanted to add a method that worked for me with barrier using `ffmpeg`. This will share desktop audio only (not microphone input). In this example, the client is Ubuntu, and the server is Windows. ffmpeg will need to be installed on both. Other scenarios will need a different command and understanding of ffmpeg. On the "client", run the ffmpeg command: `ffmpeg -re -f alsa -ac 2 -i default -f rtp rtp://server:1234` Where `server` is your barrier server IP address. This will stream desktop audio to the specified address (If you use pulse instead of alsa, replace `-f alsa` with `-f pulse` ) It will output something like: ``` SDP: v=0 o=- 0 0 IN IP4 127.0.0.1 s=No Name c=IN IP4 192.168.1.82 t=0 0 a=tool:libavformat 58.21.100 m=audio 1234 RTP/AVP 97 b=AS:768 a=rtpmap:97 PCMU/48000/2 ``` In my example the server is `192.168.1.82` On the server machine (`192.168.1.82`), copy the SDP text above into a file `sdp_file` and run the ffplay command: `./ffplay -protocol_whitelist 'rtp,file,udp' .\sdp_file` Enjoy streamed low-latency audio. I could see this potentially working inside barrier in the future, so here's a little inspiration and direction in case anyone has time for a fork.

gitea-mirror commented

2026-05-05 05:44:18 -06:00

Author

Owner

@AndreTomasGraca commented on GitHub (Feb 3, 2021):

Hi!

This somehow did not work for me...

I did everything as you said, @Vigrond, except that I had to change
./ffplay -protocol_whitelist 'rtp,file,udp' .\sdp_file to ffplay.exe -protocol_whitelist rtp,file,udp C:\ffmpeg\bin\sdp_file.sdp because that is the correspondent for Windows (don't you need to correct that in your post, or did I misunderstand something?)

I got no errors, but I do not seem to be receiving any audio.

Anyone can help?

André

@AndreTomasGraca commented on GitHub (Feb 3, 2021): Hi! This somehow did not work for me... I did everything as you said, @Vigrond, except that I had to change `./ffplay -protocol_whitelist 'rtp,file,udp' .\sdp_file` to ffplay.exe -protocol_whitelist rtp,file,udp C:\ffmpeg\bin\sdp_file.sdp because that is the correspondent for Windows (don't you need to correct that in your post, or did I misunderstand something?) I got no errors, but I do not seem to be receiving any audio. Anyone can help? André

gitea-mirror commented

2026-05-05 05:44:21 -06:00

Author

Owner

@Qwerty-Space commented on GitHub (Oct 4, 2022):

Just wanted to add a method that worked for me with barrier using ffmpeg. This will share desktop audio only (not microphone input).

In this example, the client is Ubuntu, and the server is Windows. ffmpeg will need to be installed on both. Other scenarios will need a different command and understanding of ffmpeg.

On the "client", run the ffmpeg command:

ffmpeg -re -f alsa -ac 2 -i default -f rtp rtp://server:1234

Where server is your barrier server IP address. This will stream desktop audio to the specified address

(If you use pulse instead of alsa, replace -f alsa with -f pulse )

It will output something like:
SDP:
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 192.168.1.82
t=0 0
a=tool:libavformat 58.21.100
m=audio 1234 RTP/AVP 97
b=AS:768
a=rtpmap:97 PCMU/48000/2
In my example the server is 192.168.1.82

On the server machine (192.168.1.82), copy the SDP text above into a file sdp_file and run the ffplay command:

./ffplay -protocol_whitelist 'rtp,file,udp' .\sdp_file

Enjoy streamed low-latency audio.

I could see this potentially working inside barrier in the future, so here's a little inspiration and direction in case anyone has time for a fork.

@Vigrond sorry to necropost. This works for me. However, it's very high-latency, probably about 5 seconds of lag. Do you know of anything I can do to reduce it?

It shouldn't be high-latency, as they're both connected to the same 1G switch, and have a ping of <1ms

@Qwerty-Space commented on GitHub (Oct 4, 2022): > Just wanted to add a method that worked for me with barrier using `ffmpeg`. This will share desktop audio only (not microphone input). > > In this example, the client is Ubuntu, and the server is Windows. ffmpeg will need to be installed on both. Other scenarios will need a different command and understanding of ffmpeg. > > On the "client", run the ffmpeg command: > > `ffmpeg -re -f alsa -ac 2 -i default -f rtp rtp://server:1234` > > Where `server` is your barrier server IP address. This will stream desktop audio to the specified address > > (If you use pulse instead of alsa, replace `-f alsa` with `-f pulse` ) > > It will output something like: > > ``` > SDP: > v=0 > o=- 0 0 IN IP4 127.0.0.1 > s=No Name > c=IN IP4 192.168.1.82 > t=0 0 > a=tool:libavformat 58.21.100 > m=audio 1234 RTP/AVP 97 > b=AS:768 > a=rtpmap:97 PCMU/48000/2 > ``` > > In my example the server is `192.168.1.82` > > On the server machine (`192.168.1.82`), copy the SDP text above into a file `sdp_file` and run the ffplay command: > > `./ffplay -protocol_whitelist 'rtp,file,udp' .\sdp_file` > > Enjoy streamed low-latency audio. > > I could see this potentially working inside barrier in the future, so here's a little inspiration and direction in case anyone has time for a fork. @Vigrond sorry to necropost. This works for me. However, it's very _high-latency_, probably about 5 seconds of lag. Do you know of anything I can do to reduce it? It shouldn't be high-latency, as they're both connected to the same 1G switch, and have a ping of <1ms

No labels

Rows
Columns