-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Audio #4
Comments
I've looked into audio while developing the macOS version of this driver. It doesn't seem too complicated, but I'm not sure how to implement Linux audio devices in user mode. |
I can connect my arctis 9x pro to my linux machine via bluetooth, but I'm stuck using the ad2p bluetooth interface, so I can't use the headset's mic. I used XOW to allow the xbox usb adapter to connect to my headset, but my I couldn't find the headset in linux. Is there anything specific you need help with in order to connect a headset using the xbox wireless adapter? |
The first step would be to create input and output audio devices for the headset but I'm not even sure if that's possible from user mode on Linux. If this can only be done from kernel mode then it's impossible for me to implement this in xow. |
hhhmmm... When I connect my headset I didn't see the device anywhere. So even if I were able to create the output and input devices, I couldn't link them to anything. |
Yeah, this is way too much work for me right now, considering I don't even have a device/headset to test this with. I may implement this for a 1.0 release of xow. |
I think you need a headset with 3.5mm to connect to the gamepad. |
Use xbox device as Pulseaudio audio sink and source . |
That makes sense. I don't actually own a xbox controller so this doesn't work. I used to have a arctis 9x, but i've returned it since I wasn't able to use it wirelessly in linux (except for bluetooth). |
I did some packet capturing and reverse engineered the important parts of the protocol:
Those things would have to be implemented in xow (using PulseAudio). The timing of the individual packets (8 ms) is VERY important (that might be the biggest problem). |
@LorenzoMinutolo I'm currently focusing on implementing the audio for the controllers first, I might consider supporting third-party headsets for a future release. |
I've implemented experimental headphone support, available in the Important notes: You will have to install the PulseAudio libraries to compile xow. The PulseAudio daemon is usually running as a user-service and refuses any connections from root accounts. That's why I've decided to convert xow's system-service to a user-service. You will have to uninstall the system-service ( |
I just tried the First I could not compile it, but after performing I also did But I can not
Running the
The PulseAudio daemon is running (I don't know if this information is helpful):
|
@andreashuetter Make sure to run |
Well, the reason why I tried it with
But now I tried But it doesn't seem to work at all. After I rebooted the machine, and it says it's not active:
|
Silly me, of course Of course,
But after some trying I fear that this version of xow is not suited for SteamOS. The thing is, when SteamOS gets started it always starts in Big Picture Mode and everything is run by the user So whenever I had to do something like checking out xow from github, compiling it and installing it, I did this as user I switched back to the (system-service) |
Hmm, I think you could try using the old |
I tried on Fedora 31, built and worked up until I plugged in a pair of headphones, then crashed: Kernel: 5.5.15-200.fc31.x86_64
|
I tried what you suggested: Using the old
When I stop the xow service and start xow manually to get more info then it keeps printing that it has detected the audio device, but never stops printing this (even if I disconnect the headphone it keeps printing these lines) until I press Ctrl+C:
|
@TauAkiou It looks like it identified your headphones as an input device. I fixed this problem in the latest commit, but you might run into the same issue as @andreashuetter.
Yes, it creates an audio sink for the controller's input (currently non-functional) and an audio source for the output. In your case, it seems to get stuck during the audio initialization (it should normally log |
Building audio branch and running xow from source directory I get the following output
That's with headset plugged in; without it runs normally |
@Aerol I've just pushed out a commit that should fix this issue. |
It has indeed!
|
@andreashuetter Your issue should most likely be fixed now (didn't need the USB capture). |
I don't think so. bluez-alsa is definitely userspace app and it creates sink device. EDIT: There is a comment in the issue 48 that outlines other possible solutions via Alsa. |
I know about |
OK, thank you Severin. I do not agree with you, nevertheless I accept your decision on your (actually nice) project. 👍 I do not use Pulse Audio at all, just Alsa and I do not have any problems with it. I do not know any app that does not with Alsa but Pulse Audio. In fact Pulse Audio could utilize underlying Alsa. Nevermind. |
The problem is that applications like Discord show you a list of PulseAudio sinks and sources (at least if you've got PulseAudio installed). They simply don't give you an option to select which Alsa sink/source you want your output/input to go to. In fact, PulseAudio provides an Alsa device which allows legacy Alsa-only applications to interface with PulseAudio over their plugin. |
I examined audio branch from some repo that forked this one before when audio branch existed (sweet times 😢 ). Basically, I think you made a good approach with simple API from PulseAudio (note that maybe async API will give better results. I managed to make some async API integration but as there were a lot of callbacks and controller needed to receive exact 0x600 bytes of data, that means threads and internal buffers implementation so I gave up for just POW case 😄 ) The only thing that should have been added that could be the key to the remaining problems is to create ALSA virtual device and connect with PulseAudio simple API to it. PulseAudio should automatically detect created ALSA virtual device so Discord user-case or any that needs PulseAudio should work. From there, PulseAudio simple(or async) API can be handled from xow and sent to controller(or to the virtual driver for mic). |
Hi guys, After a wild adventure with ALSA drivers, I gave up and found more simple solution: After calling
and
Note: difference is that 4th parameter is changed from nullptr to the name of the module we created. After this, the audio was able to play only on headphones after selecting them from PulseAudio menu. For the microphone to work, there must be another module created only for microphone capture. If I understood correctly in xow there must be 2 use-cases detected: Hope this is good progress for you and if you agree to integrate audio branch back with this changes included, I can continue on checking microphone pipeline that is needed. 😄 |
Like I said in one of my earlier comments, I think if we're going to going to use PulseAudio's API for this then we'd be better of using Now here's a solution that I'd imagine would work pretty well:
Either the suggestion outlined above or a dedicated PulseAudio module would work, I think. |
I think that split-design is the best suggestion: Input devices should be created by system services because udev and logind already setup the permissions etc, connecting to pulse audio is a user service, so it needs to be the proxy between the xow system server and pulseaudio user service and it would probably be pretty light-weight. You could use dbus to signal the user service connection to the system daemon. For multiuser setups, there's "just" one thing to solve: You should track which user session currently claims the input device and only signal that particular user daemon. It should not be possible for other user sessions to "listen" to the audio. |
The problem with piping is that you must always have a reader on the other side or the reproduction of the sound will block. That can block write() function in xow if I am not mistaken.
This is overthinking. If multi-user case is a big issue, a install script option that runs PulseAudio in system-wide mode can resolve this (if anybody actually cares if xow is system wide or not). No need to add another layer just for case that will probably never happen. |
According to
You'd have to add an option that runs xow in system-wide mode though, not PA.
Would you expect your mouse or keyboard to turn off as soon as you logged out though? I certainly wouldn't. I believe nobody expects their input devices (or any device for that matter) to be bound to the lifetime of a specific user session. Oh, and there people who run multi-user systems (take a look at this comment). |
Short answer: No... Long answer: Also, I don't see why blocking in xow would be an issue as the writer could be implemented in a separate thread without blocking the main thread. It actually should be done that way. Also, the xow system service that receives the sound endpoint, doesn't even write directly to pa (except you manage to pass FDs around), it will probably be a proxy and should do reads and writes in separate threads anyways. The xow audio handler and input handler must be separate threads. |
You are right, but, the problem that other audio apps also cannot play any audio until you start read thread from xow. So all audio on the system is blocked by the speed of xow read. I am not sure if this is OK as there are a lot of use-cases in my head that can block something. 😄 I also couldn't connect headphones with pipe module when testing my changes. With null sink, there is no block so connection was successful every time. I am not sure right now what is the idea for read/write. I was suggesting to use null sink for audio playback on the headphones by monitoring the sink and for microphone to use pipe module but instead of PulseAudio API just write to the FIFO file. But now I think that was also your idea, right?
I see the Steam OS issue, but I also can see from this comment that Steam OS is running pulse audio system wide and not --user, so running system-wide xow with audio patches would be a solution to this actually as I said in the comment that PA system-wide would solve this. Right?
Not sure about this. Wouldn't it be easier for user-space daemon to send to xow that he is active when he start, so xow can start communication with him when audio is connected? |
I think it needs a two-way handshake:
At any time, the user session daemon should probably read and write audio but only relay it from/to the system wide daemon if it was actually announced. Until then, it just relays (generated) silence... That is unless there's a way to dynamically attach to the pipe API of PA and create sinks on the fly. That way it should not block if something isn't online. Everything that goes deeper is currently out of my scope as I didn't look into the implementation details of the PA API. And also I'm currently still very busy with xpadneo and thus didn't dug much into the code of xow. It would be an interesting project of converting the dongle driver to a native kernel driver and see if we can expose the controller on the input bus there. This would make it possible to also expose a real audio device. |
Any news about audio integration ? |
@medusalix first of all, thank you for xow and your work. I respect that very much! I've been looking for a better wireless headset that can send and receive good audio at the same time since the covid crap. With the SteelSeries Arctis 9X Wireless Gaming Headset I found what I was looking for. On Windows it works great with Teams, Discord, Webex and Zoom. However, I would very much like to move on to Linux and not always have to switch to windows for meetings, for example. I hope you don't mind my novel, but it would be a real highlight for me if this would work with the Pulseaudio connection. If I can support you in any way, just say a word. :) |
It can be very hard to devote dev time to an open source project when life is applying pressure, if you aren't able to contribute code our friendly xow dev accepts donations! 😀 There is a donate link on the xow README, here it is for convenience. I always encourage those who are financially sound & enjoying an open source project to consider buying the devs a coffee to show their appreciation 🌈 Not everyone is in a financial position to do so, and that's okay too. Keep in mind things like answering community questions if you are able, providing troubleshooting, checking grammar and spelling, fleshing out READMEs & docs, managing a packaging aspect, many other things like this besides code can be a great help to a project. ❤️ |
True. In the first place, I meant it more technically. Like for example create a suitable USB sniff under Windows or similar. Otherwise, I'm more in the Web / Java area on the road. On my annual list is xow already, but to avoid fees, they take place only 1 time a year. Sounds a bit strange but it is partly unbelievable how much in fees for donations to the service providers falls off. The idea with the documentation and issue responses is good. |
Hi, sorry for the delayed response. @sorryusernameisalreadytaken, @Merrit Thank you so much for your support! |
One general question regarding audio: How are multiple controllers handled? would it be possible to attach headphones to both controllers and have the same audio? This use-case exists for local multiplayer games |
Each gamepad is handled separately. You get individual input and output devices for every controller.
That depends on the audio server you're using. For PulseAudio there's an option to simultaneously output audio to all devices. |
@sorryusernameisalreadytaken I also have an arctis 9x headset with the Microsoft Xbox Wireless adapter. Everything works fine in windows 10, but I tried Ubuntu 20.04 with Xow and it doesn't appear as an audio device or microphone, did you manage to connect your headset in linux? Can I use the headset with audio and microphone for google meet? Steam games? I would appreciate your help. |
Hello francisco-gamonal. Yes, you can use your arctis 9x headset with Linux but just with bluetooth at the moment. And sadly I need to say that the Headset-Audio protocol on Linux is not nice. Android's headset protocol is quite better and the propriatary Windows Headset protocol is one of the Best I know. By the way: Bluetooth is not cool for sending and receiving audio in the same moment. This is the reason I have a lot of hope for xow. xow could be the first solution to have a loseless Headset working on linux. |
The audio branch, as far as I've noticed, was dropped a long time ago and according to the readme.md, xow hasn't been regularly worked on for quite awhile now. The author is planning on replacing it with a proper kernel driver, which is poised to fix lots of the core issues Xow as far as I could always tell was never written with audio headsets in mind, either - just controllers. I would recommend tracking progress on xone (https://github.com/medusalix/xone), which currently doesn't have support for the wireless dongle but is likely to at some point. |
@sorryusernameisalreadytaken thanks for your answer, right now I am using the headset with windows with dongle and in android by bluetooh, since with ubuntu through bluetooh the audio quality seems bad and the microphone does not work. @TauAkiou I'm going to follow up on the xone project, maybe in the near future it will have dongle support in linux. |
I've released a new driver for the Xbox wireless dongle that features audio input and output. You can check it out here. |
Does this driver support audio? Or are there plans to?
The text was updated successfully, but these errors were encountered: