Skip to content
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

24bit files distortions problem at raspbian armv7l GNU/Linux if the internal player volume control is set to any value less than +0dB #1978

Closed
eshchenko opened this issue Feb 27, 2018 · 10 comments

Comments

Projects
None yet
2 participants
@eshchenko
Copy link

commented Feb 27, 2018

Dear Developers

I do understand, that my problem is rather exotic, but there is a big underestimate of the deadbeef
beauty in the Raspberry Pi community.
Meanwhile, recently they finally made the snd_usb_audio module for raspbian compatible with the 24bit.
Also, last alsa utilities programs and libraries work as expected (24bit is supported)...
So, I hope it is time to support the Raspberry....

Steps to reproduce the problem

Connected external usb card to Raspberry PI2:
DR DAC Prime:
pi@raspberrypi:~/development/alsacap $ ./alsacap
*** Scanning for playback devices ***
Card 0, ID ALSA', name bcm2835 ALSA'
......
**Card 1, ID prime', name Dr. DAC prime'
Device 0, ID USB Audio', name USB Audio', 1 subdevices (1 available)
2 channels, sampling rate 8000..96000 Hz
Sample formats: S16_LE, S24_3LE
Subdevice 0, name subdevice #0'** Device 1, ID USB Audio', name USB Audio #1', 1 subdevices (1 available) 2 channels, sampling rate 48000..48000 Hz Sample formats: S16_LE Subdevice 0, name subdevice #0'

Compile DeadBeaf from the source.
Be sure the external usb card is used the most direct way:
DeadBeeF configuration:
ALSA output plugin
Output device: Dr DAC Direct Hardware Device without any conversions
ALSA resampling is not checked

Take a 24bit file, be sure that it can be played correctly by the aplay:
pi@raspberrypi:~/development/bin $ aplay -D hw:CARD=prime,DEV=0 tmp.wav
Playing WAVE 'tmp.wav' : Signed 24 bit Little Endian in 3bytes, Rate 48000 Hz, Stereo

Start to play this 24bit pcm (*.wav) file by the deadbeef player.

Cross-check that the hardware and alsa module work as expected e.g by inspecting
/proc/asound/ tree

What's going on? Describe the problem in as much detail as possible

Huge distortion,
but only if the internal player volume control is set to any value less than +0dB

If the volume is at maximum, the sound is clean without any distortion.

Temporary solution:
Similar to suggested in
#1908

  1. set volume to maximum
  2. remove the volume control widget

The same card connected to the PC ( x86_64 GNU/Linux ) plays the 24bit without any distortion
independent on the volume control value (e.g. -6db),
so the problem reported is most probably related with the arm architecture.

Recommendation for the future -

  1. be sure that the default value of the playback.volume is 0.0 like mine:
    pi@raspberrypi:~/development/bin $ grep -a playback.volume ~/.config/deadbeef/config
    playback.volume 0.0000000
  2. do not use playback.volume

Information about the software:

Deadbeef version:
Development, also tested at
0.7.2
0.7.0
etc

OS:
Paspberri Pi 2B
Raspbian GNU/Linux 8 (jessie)
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

For me, the problem described is rather a feature and no action is needed,
but who knows, may be some person would like to use separate volume control.

Best regards,
Dmitry Eshchenko

p.s. It is interesting to note that mplayer works fine even with the volume option:

mplayer -volume 50 -ao alsa:device=hw=1.0 tmp.wav
mplayer -af volume=-3.0:0 -ao alsa:device=hw=1.0 tmp.wav

@Alexey-Yakovenko

This comment has been minimized.

Copy link
Collaborator

commented Feb 27, 2018

@eshchenko

This comment has been minimized.

Copy link
Author

commented Feb 27, 2018

@Alexey-Yakovenko

This comment has been minimized.

Copy link
Collaborator

commented Mar 9, 2018

As for your comment that you already corrected this problem few month ago -
have you tested this on the real ARM hardware and on the fresh Raspbian?

Yes, but without Raspbian, was fixing this for android.

@Alexey-Yakovenko

This comment has been minimized.

Copy link
Collaborator

commented Mar 9, 2018

Please try this patch

--- a/streamer.c
+++ b/streamer.c
@@ -1815,7 +1815,7 @@ streamer_apply_soft_volume (char *bytes, int sz) {
             if (ivolume != 1000) {
                 int third = bytesread/3;
                 for (int i = 0; i < third; i++) {
-                    int32_t sample = ((unsigned char)stream[0]) | ((unsigned char)stream[1]<<8) | (stream[2]<<16);
+                    int32_t sample = ((unsigned char)stream[0]) | ((unsigned char)stream[1]<<8) | ((signed char)(stream[2]<<16));
                     int32_t newsample = (int32_t)((int64_t)sample * ivolume / 1000);
                     stream[0] = (newsample&0x0000ff);
                     stream[1] = (newsample&0x00ff00)>>8;
@eshchenko

This comment has been minimized.

Copy link
Author

commented Mar 9, 2018

@Alexey-Yakovenko

This comment has been minimized.

Copy link
Collaborator

commented Mar 10, 2018

oh .. I actually made a typo..

should be this instead

--- a/streamer.c
+++ b/streamer.c
@@ -1815,7 +1815,7 @@ streamer_apply_soft_volume (char *bytes, int sz) {
             if (ivolume != 1000) {
                 int third = bytesread/3;
                 for (int i = 0; i < third; i++) {
-                    int32_t sample = ((unsigned char)stream[0]) | ((unsigned char)stream[1]<<8) | (stream[2]<<16);
+                    int32_t sample = ((unsigned char)stream[0]) | ((unsigned char)stream[1]<<8) | (((signed char)stream[2])<<16);
                     int32_t newsample = (int32_t)((int64_t)sample * ivolume / 1000);
                     stream[0] = (newsample&0x0000ff);
                     stream[1] = (newsample&0x00ff00)>>8;
@eshchenko

This comment has been minimized.

Copy link
Author

commented Mar 10, 2018

@Alexey-Yakovenko

This comment has been minimized.

Copy link
Collaborator

commented Mar 11, 2018

FYI: it doesn't seem like equalizer issue is related to volume control in any way.
There was another issue with EQ on trunk which might have caused it. I'll verify.

@eshchenko

This comment has been minimized.

Copy link
Author

commented Mar 11, 2018

@Alexey-Yakovenko

This comment has been minimized.

Copy link
Collaborator

commented Mar 12, 2018

Yes, please make a new issue about the EQ.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.