![]() ![]() ![]() My testing method to measure audio latency is the following: Testing was done with the patch I described along with a few common PulseAudio configuration adjustments (that I’ll give later in the article). Maybe this could be moved into an entry in the Windows registry, but I figured this was the most simple solution for now. I named it this way as the wine staging patches also use environment variables beginning with STAGING. As you may have understood by looking at the code, I made it adjustable at runtime with the STAGING_AUDIO_DURATION environment variable. That means we can manipulate this value to make “audio slices” whatever length we want. To my understanding, duration is directly requested by the application, but we don’t have to hold on to it. The name is pretty explicit, it initializes the audio client so it is likely to be somewhere we can make adjustments to improve latency. The function I added this slice of code in is AudioClient_Initialize. If (duration ss) * MulDiv(period, This->ss.rate, 10000000) I just applied suggestions from the PulseAudio Latenc圜ontrol wiki page -1767,6 +1767,13 Uh oh, really low latency requested. This one edits flags and attributes to request lower latency from PulseAudio. Pa_stream_get_state(stream) = PA_STREAM_CREATING) While (pa_mainloop_iterate(ml, 1, &ret) >= 0 & + ret = pa_stream_connect_record(stream, NULL, &attr, PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS|PA_STREAM_ADJUST_LATENCY) ret = pa_stream_connect_record(stream, NULL, &attr, PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS) + PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS|PA_STREAM_ADJUST_LATENCY, NULL, NULL) PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS, NULL, NULL) Ret = pa_stream_connect_playback(stream, NULL, &attr, Stream = pa_stream_new(ctx, "format test stream", &ss, &map) + attr.tlength = agsize = pa_usec_to_bytes(1000, &ss) attr.minreq = agsize = pa_frame_size(&ss) I’ll comment it hunk by -406,9 +406,9 = map.channels But before we get into results, let’s have a look at the patch first. It took quite some time, but I ended up with a patch to winepulse.drv that is stable and capable of providing very low latency. With all of that in mind, I tried optimizing latency elsewhere: inside the Wine PulseAudio driver. It also has many functionalities I appreciate as a Twitch streamer (networking, null sinks and loopbacks). PulseAudio is never going to be the audio server with the lowest latency by design, but it doesn’t mean it can’t achieve very low latency either. Despite those downsides, I almost never tried going without PulseAudio - especially as I intended to record/stream my gameplay. However, that also often meant reducing compatibility with other applications needing audio, or not being able to have osu! running alongside another audio software. With appropriate configuration (but dozens of headaches), you could eventually get a perfect osu! setup, matching Windows’ latency without PulseAudio. To tackle that, players used to either use another audio server (or straight go with ALSA, as Wine doesn’t support JACK anymore) or tweak their PulseAudio config to reduce latency. That means by default, there’s a very noticeable high latency (that is noticeable even on other games, without Wine). We are hardcore Linux rhythm gamers! (I honestly hope I’ll never say that again.) It will meet about anyone’s expectations, but ours. However, it is also usually shipped with configuration files to meet nearly perfect stability on any kind of systems. It is a very capable, modern audio server providing many functionalities. Usually, Linux distros nowadays are shipped with PulseAudio. To make it simple, we’ll consider two main sources of audio latency: the audio server & the audio source (Wine/the game). ![]() There has always been a recuring issue though: audio latency. Its performance, in terms of frames-per-seconds, has since been identical if not better than on Windows on most hardware. Since that update, osu! on Linux has been nearly painless to install and play on, compared to other games relying on Wine. What that meant for us Linux users, is that Wine didn’t have to convert DirectX calls to OpenGL anymore! For some reason, the OpenGL rendering engine of the game never worked on Wine - but fortunately, that osu! update fixed it. It was a huge update, as the osu! engine was rewritten to only support OpenGL and drop DirectX support. Osu! has been running nearly flawlessly since the “OpenGL update” that happened late 2015. It has been running fine under Wine for almost a decade already ( the first guide on the osu! forums goes back to 2009)! Getting it to work perfectly, to meet my top player needs, is another story though. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |