Re: portaudio: only OSS host API available since version 19.20210406-2
Hi, In my environment, portaudio with MME support generates choppy sound for the suggestedOutputLatency of less that 60 ms. 70 ms seems to work. In this case, hostBufferCount=8 and hostBufferSizeFrams=480 if the sample rate is 48 kHz. So, total buffer length is 3840 samples. Therefore, the resulted latency is 80 ms. interesting. I've now did some experiments with a self compiled portaudio with MME and WASAPI and both worked flawless on my machine with a suggestedLatency of 10ms. Perhaps this is dependend on the sound card used in the computer. The callbacks are called with framesPerBuffer of 480. OSS implementation in cygwin 3.4.9 always uses the buffer size of 125 ms. So, even if hostBufferCount=2 (current value of portaidio with OSS support), the latency is 250 ms. This might not be acceptable for some applications. I wouldn't mind using OSS if it supports lower hostBufferSizes so that I don't get callbacks with a buffer size of 6000. Apparently suggestedLatency has no influence on that. Unfortunately, OSS and MME/DSound/WASAPI can be exclusively enabled. I am currently considering whether to rollback portaudio to MME/ DSound/WASAPI until cygwin 3.5.0 is released. I guess it would be possible but would probably require a patched configure script. Either way if you change it away from OSS or now, I hope I could provide some useful feedback. Best regards, Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Setup Ver 2.926 (64bit):can't file extract from qt5-webkit-debuginfo
ASSI via Cygwin writes: > I could reproduce that issue, no time yet to dig deeper. It looks like > the decompressor loses track of where it is, then uses whatever data > comes after that to try and extract the next file (which obviously > doesn't look like it's expected to). Both GNU tar and bsdtar (from libarchive) decompress the archive correctly, so that would allow you to install manually. Looking at the file that produces the failure, it is quite a bit larger than 2GiB, so I think that this simply means that the canned tar extractor in setup.exe is just not large-file safe. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: SDL2: Gamepads stopped working
On Thu, 5 Oct 2023 17:15:42 +0200 risingpowe wrote: > On 05.10.2023 16:12, Takashi Yano wrote:> > > I guess DirectInput is necessary for that gamepads. I will release > > SDL2 2.28.4-1 (TEST) package shortly, where both dinput and xinput > > are enabled. Could you please test? > > > > Thank you very much! > > My gamepads show up, but do not work. > - SDL_NumJoysticks() is now correct: 2 > - The USB HID controller generates this SDL_GetError() for > SDL_GameControllerOpen(): > IDirectInputDevice8::SetCooperativeLevel() DirectX error 0x80070006 > - And SDL_JoystickNameForIndex() only returns one character "U" instead > of "USB Gamepad" > - XBOX360 controller identifies itself correctly as > "Xbox 360 Controller", but does not work. Thanks for testing! What error occurs for XBOX360 controller? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: SDL2: Gamepads stopped working
On 05.10.2023 16:12, Takashi Yano wrote:> > I guess DirectInput is necessary for that gamepads. I will release > SDL2 2.28.4-1 (TEST) package shortly, where both dinput and xinput > are enabled. Could you please test? > Thank you very much! My gamepads show up, but do not work. - SDL_NumJoysticks() is now correct: 2 - The USB HID controller generates this SDL_GetError() for SDL_GameControllerOpen(): IDirectInputDevice8::SetCooperativeLevel() DirectX error 0x80070006 - And SDL_JoystickNameForIndex() only returns one character "U" instead of "USB Gamepad" - XBOX360 controller identifies itself correctly as "Xbox 360 Controller", but does not work. What options have you added to ./configure? IMHO just leave blank. This way at least one category of controllers should work. Best regards, Richard -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: SDL2: Gamepads stopped working
On Thu, 5 Oct 2023 15:07:54 +0200 risingpower wrote: > On 03.10.2023 14:26, Takashi Yano wrote: > > This is because SDL_mmjoystick.c is removed from the source tree > > of upstream since 2.0.18. > > > > Now I am trying to enable SDL_dinputjoystick.c or SDL_xinputjoystick.c > > instead. Hopefully it will work again in 2.28.4. > > > > I compiled SDL 2.28.4 and XInput gamepads work again. (XBOX360 controller) > HID gamepads do NOT work. I guess they did not work when I did the tests > 2 years ago. I guess DirectInput is necessary for that gamepads. I will release SDL2 2.28.4-1 (TEST) package shortly, where both dinput and xinput are enabled. Could you please test? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: SDL2: Gamepads stopped working
On 03.10.2023 14:26, Takashi Yano wrote: > This is because SDL_mmjoystick.c is removed from the source tree > of upstream since 2.0.18. > > Now I am trying to enable SDL_dinputjoystick.c or SDL_xinputjoystick.c > instead. Hopefully it will work again in 2.28.4. > I compiled SDL 2.28.4 and XInput gamepads work again. (XBOX360 controller) HID gamepads do NOT work. I guess they did not work when I did the tests 2 years ago. If I use the SDL2 dll from mingw, also my HID controllers work. Not sure what's the magic here. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: portaudio: only OSS host API available since version 19.20210406-2
Sorry for late reply. On Sat, 30 Sep 2023 01:12:22 +0200 Michael Panzlaff wrote: > thank you for the quick reply. I checked my program again and there was > indeed a bug which prevent OSS from working. Though, it's not really OSS > what was the problem. The problem was the huge buffer size that OSS causes. > > I set a suggested latency of 0.008 (which is what I obtain from > defaultLowOutputLatency) and the audio callback get's a framesPerBuffer > size of 6000! At 48 kHz that is more than 100 ms of latency. I'm not > suggesting that MME is the best solution, but it was able to get > something below 50 ms (not sure what defaultLowOutputLatency was with that). In my environment, portaudio with MME support generates choppy sound for the suggestedOutputLatency of less that 60 ms. 70 ms seems to work. In this case, hostBufferCount=8 and hostBufferSizeFrams=480 if the sample rate is 48 kHz. So, total buffer length is 3840 samples. Therefore, the resulted latency is 80 ms. OSS implementation in cygwin 3.4.9 always uses the buffer size of 125 ms. So, even if hostBufferCount=2 (current value of portaidio with OSS support), the latency is 250 ms. This might not be acceptable for some applications. Now I am trying to reduce latency of OSS implementaion in cygwin 3.5.0, and I could reduce the latency to 3840 samples so far. > Is there a difference when building portaudio for Cygwin instead of > native Windows? Is there a specific reason why MME, DirectSound, WASAPI > are not available? Do they cause maintenance overhead? Unfortunately, OSS and MME/DSound/WASAPI can be exclusively enabled. I am currently considering whether to rollback portaudio to MME/ DSound/WASAPI until cygwin 3.5.0 is released. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
