[BUG] Windows 10 fails to play anything.

[TLCFEM]

Launching v1.8.8, the log window pops up.

From the log, it tries to use portaudio but gets the following message:

Unsupported format. Invalid number of channels.

Then the program switches to null plugin. Nothing can be played.

v1.8.8 does not work, nightly build does not work. v1.8.7 works.

The error message comes from line 284 of portaudio.c. The latest 3 commits may break it.

Deadbeef version: 1.8.8

OS: Windows 10

[kuba160]

There wasn't anybody reporting portaudio problems for 1.8.8 and master, and I don't experience any issues. I am not aware of any recent changes that could break portaudio output. To narrow the issue down you could try to do these things:

• Test on clean config (located in %APPDATA%/deadbeef for standalone versions, main dir for portable)
• Test with different files (different samplerate/channels/bit precision)
• Test with different output devices

Also not sure if it would be useful but you could write what output device you have.

[TLCFEM]

Thank you very much for swift response. Please check the attached screenshots.

[TLCFEM]

What I have as the default output is Sony WH-1000XM3, when disconnected, v1.8.8 works fine. When connected it does not work. v1.8.7 works with no issues regardless of headphone connection.

[kuba160]

Deadbeef tries to open a 44100Hz 16 bit stereo stream on start by default and this fails for some reason on newest version. Does copying old portaudio plugin into newer version fix the issue? It is possible something has changed in portaudio codebase.

EDIT: You also should try to copy libportaudio.dll

[TLCFEM]

Overwriting the portaudio plugin portaudio.dll with the old version does solve the problem. Then it is a problem of upstream I presume.

[kuba160]

Did you copy libportaudio.dll as well? portaudio.dll should be identical across versions. If replacing libportaudio.dll fixes the issue then the issue has to be upstream (unless the api changed which I doubt).

EDIT: I see that libportaudio filename changed. I managed to reproduce the issue with my bluetooth headset, but only in headset mode; in headphones mode it works fine.

[TLCFEM]

The two portaudio.dll files have different sizes, not sure if they are the same version. Overwriting portaudio.dll alone does not actually solve the problem, the previously claim is false. It directly leads to null plugin so no error message.

Overwriting libportaudio.dll indeed solves the problem, checked log and active output plugin.

[TLCFEM]

Exactly it happens in headset mode.

EDIT: I see that libportaudio filename changed. I managed to reproduce the issue with my bluetooth headset, but only in headset mode; in headphones mode it works fine.

[kuba160]

Interestingly the headset device shows as 1 channel device in Windows sound settings - which makes no wonder that portaudio sees it as 1 channel:

And the sound quality is very poor. Not sure if previous portaudio does manage to change the device output or just mix it to mono behind. I guess I should make sure that no lockup happens in deadbeef when such device is encountered.

[TLCFEM]

On my machine, this one is better than the other one.🤣🤣🤣

Anyway, guess I created some extra work for you.