search

mkckr0 / audio-share

Audio Share can share Windows/Linux computer's audio to Android phone over network, so your phone becomes the speaker of computer. (You needn't buy a new speaker😄.)
Apache License 2.0
902 stars 43 forks source link

[BUG] Audio crackles heavily with certain audio-devices #14

Closed Switch123456789 closed 9 months ago

Switch123456789 commented 11 months ago

Describe the bug Audio crackles heavily with certain audio-devices in windows.

Audio-devices (mine)

Audio-devices (friend's)

To Reproduce

  1. Start audio-share-server as usual
  2. Connect with android-app
  3. audio crackles heavily

Expected behavior

Server (mine):

Server (friend's):

Android (mine):

Android (friend's):

mkckr0 commented 11 months ago

Can you provide the server.log of producing crackles?

Switch123456789 commented 11 months ago

Sure!!

[2023-10-26 16:17:49.325] [server] [info] tcp listen success on 192.168.0.4:65530
[2023-10-26 16:17:49.325] [server] [info] endpoint_id: {0.0.0.00000000}.{738d09c1-08f4-40b5-81a0-e8450a666674}
[2023-10-26 16:17:49.325] [server] [info] udp listen success on 192.168.0.4:65530
[2023-10-26 16:17:49.326] [server] [info] server started
[2023-10-26 16:17:49.326] [server] [info] select audio endpoint: HEADSET (Sound Blaster G3)
[2023-10-26 16:17:49.329] [server] [info] WAVEFORMATEX: wFormatTag: 65534, nBlockAlign: 8
[2023-10-26 16:17:49.330] [server] [info] AudioFormat:
format_tag: 3
channels: 2
sample_rate: 48000
bits_per_sample: 32

[2023-10-26 16:17:58.745] [server] [info] accept 192.168.0.5:44776
[2023-10-26 16:18:19.275] [server] [info] server stopped

We also tried changing the sample-rate and bit-depth of the audio-adapters but nothing changed. Btw, none of the adapters are capable to playback with 32 bits per sample (because that's what audio-share uses according to the log).

I could try to record that crackling if that might give you a clue!? And/or I could boot up linux to see if the affected devices behave different in linux (arch + pipewire), just let me know.

mkckr0 commented 11 months ago

The AudioFormat seems like normal. The bits_per_sample is default and set by Windows Audio, which is always 32 on Windows.

What about the crackled sound? It's entirely meanless sound or can hear the meanful sound but with crakles?

You can use the wav_recorder.exe to record the audio of Sound Blaster G3 as a .wav file, and to hear if it's fine. wav_recorder.zip Its source code is https://www.cnblogs.com/mkckr0/p/16818674.html. Open a terminal and run wav_recorder.exe, then wait 60s, it will generate an out.wav file. Take care of the first line of output, it will print the current device, e.g. select audio endpoint: U28P2G6B (NVIDIA High Definition Audio). Make sure it's Sound Blaster G3.

Switch123456789 commented 11 months ago

Aye aye! https://drive.google.com/drive/folders/1TRYGTST1NkjTTBmR1RUs7fEZuvaVshIE I included a recording from my friend and a video that shows a discrepancy between wav_recorder.exe's alleged duration and the actual duration on my system. It doesn't make a difference if the server is running or not btw.

EDIT: I just noticed: image I guess that's referring to the discrepancy I mentioned?

mkckr0 commented 11 months ago

What's the use wall clock of your Realtek onboard-soundcard? It's also greater than 60s?

mkckr0 commented 11 months ago

What's the server.log of your Realtek onboard-soundcard? Its AudioFormat is same as HEADSET (Sound Blaster G3)?

Switch123456789 commented 11 months ago

Wav_recorder output

mkckr0 commented 11 months ago

I compare the sound of Sound Blaster G3 (server off).mkv and Sound Blaster G3 (server off).wav and find Sound Blaster G3 (server off).wav is fast from about 00:08 and the timepoint is same as delay happened. This is caused by dropped frames. It's affected by the buffer size and the sleep period. The buffer size may be different between various devices.

I modified wav_recorder.exe to let its buffer size and sleep period same as AudioShareServer.exe. Please test Sound Blaster G3 via it and to see if the use wall clock is normal. You needn't run AudioShareServer.exe when testing. wav_recorder.zip

As for crackles of Audio Share, I think it may not be caused by the buffer size and the sleep period. The buffer size has already been set to 1s, while the sleep period has been set to 1ms. It may be affected by the WIFI signal. Your headset may be the interference source. Try to move your phone close to WIFI router and away from interference source to hear if the sound is fine.

Switch123456789 commented 11 months ago

I ran the audio-share-client within windows-subsystem for android to make sure there is no chance of interference. In another attempt I connected my phone via LAN-cable (usb-adapter) to my network, just to be sure, but the results are the same. Realtek = clean & Creative = crackling.

Here's the console-output and wave-file from the modified wav_recorder:

select audio endpoint: HEADSET (Sound Blaster G3)
minimum device period: 3ms
buffer size: 48000
device period: 1
numFramesAvailable:   480 seconds: 60
use wall clock: 83s

I think the crackling is caused by many tiny audio-dropouts which wav_recorder.exe skips and thats why it sounds like fast-forward in the recording.

Switch123456789 commented 11 months ago

Oh, I forgot to mention I tried audio-share in linux recently and the sound was clean on Sound Blaster G3.

mkckr0 commented 11 months ago

AudioShareServer.exe does have this problem. The problem may be caused by the driver of Sound Blaster G3. It is not conform to the Core Audio APIs. What I can do is only to reduce the sleep period.

I add an argument to the wav_recorder.exe. You can run wav_recorder.exe 1 to set the sleep period to 1ns. If no delays, then try to increase this value to a find a proper value. Because sleep for too short period will consume more CPU resource. wav_recorder.zip

outusuke commented 11 months ago

I have the same problem, which doesn't occur in version 0.0.9

mkckr0 commented 11 months ago

I have the same problem, which doesn't occur in version 0.0.9

Do you test via wav_recorder.exe and the use wall clock also has delay? @outusuke

Switch123456789 commented 11 months ago

I did multiple runs:

300ns = 79s
250ns = 79s
200ns = 61s 62s
150ns = 60s 61s
125ns = 60s 62s 63s
100ns = 60s 60s 60s 62s
 63ns = 60s 60s 60s

The recordings sound fine whenever the wall clock was at 60s. I can confirm that 0.0.9 works fine.

eMPee584 commented 11 months ago

should be easy to bisect with v0.0.9 known as OK ..

mkckr0 commented 9 months ago

Fix at #24.