soundcard not working properly [BUG] Description

[EE1977]

Describe the bug
I managed to install and operate the pipedal succesfully with my focusrite scarlett 2i2, komplete audio 2 and MOTU2 soundcards.
Howerever, when I tried to use an irigHD2 card, a UGM192 soundcard and a TC-helicon Guitar pro there was no sound outputed or seriously distorted noise was getting out of my speakers. All of these cards are fully recognized from the system and working properly with the pi4, when pipedal service is stoped.
Please advice.

I use the pi4 chromium browser with a mouse and keyboard attached directly to pi4b, albeit the wifi direct function works fine on my android phone.

[EE1977]

P.S the input/output VU meters on the Pipedal interface indicate that the sound is present on both input and output.

[rerdavies]

Thank you for your problem report.

Let's start with one of the non-working cards, and see how we do (your choice).

1. Attach the non-working soundcard.
2. Reboot your raspberry pi.
3. Run the following command at a bash prompt:

journalctl --boot 0 | grep pipedald

And report the results here.

[EE1977]

since I am a rather newbee...:-) you mean this one?

Feb 16 19:37:28 raspberrypi pipedald[676]: lilv: lilv_get_lang(): error: Illegal LANG en_IE@euro' ignored Feb 16 19:37:28 raspberrypi pipedald[676]: lilv: lilv_get_lang(): error: Illegal LANG en_IE@euro' ignored
Feb 16 19:37:37 raspberrypi pipedald[676]: Unable to read ALSA configuration for hw:USB. hw:USB playback device not found. (No such device).
Feb 16 19:37:37 raspberrypi pipedald[676]: Audio device not configured.
Feb 16 19:41:22 raspberrypi systemd-journald[147]: Suppressed 199194 messages from pipedald.service
Feb 16 19:41:22 raspberrypi pipedald[676]: Web Socket Address: 127.0.0.1:80
Feb 16 19:41:23 raspberrypi pipedald[676]: WebSocketSession opened. ([::ffff:127.0.0.1]:51770)
Feb 16 19:41:31 raspberrypi pipedald[676]: Audio started.
Feb 16 19:41:38 raspberrypi pipedald[676]: Web Socket Address: 127.0.0.1:80
Feb 16 19:41:38 raspberrypi pipedald[676]: WebSocketSession opened. ([::ffff:127.0.0.1]:36672)
Feb 16 19:41:47 raspberrypi pipedald[676]: WebSocketSession closed.
Feb 16 19:41:53 raspberrypi pipedald[676]: Audio stopped.
Feb 16 19:41:54 raspberrypi pipedald[676]: Audio started.

[EE1977]

after opening browser 127.0.0.1 I run the command and gave the result below:

Feb 16 20:26:32 raspberrypi pipedald[608]: lilv: lilv_get_lang(): error: Illegal LANG en_IE@euro' ignored Feb 16 20:26:32 raspberrypi pipedald[608]: lilv: lilv_get_lang(): error: Illegal LANG en_IE@euro' ignored
Feb 16 20:27:10 raspberrypi systemd-journald[147]: Suppressed 211691 messages from pipedald.service
Feb 16 20:27:10 raspberrypi pipedald[608]: Listening on raspberrypi.local:80
Feb 16 20:27:10 raspberrypi pipedald[608]: Listening on 192.168.1.6:80
Feb 16 20:27:10 raspberrypi pipedald[608]: DNS/SD service announced.
Feb 16 20:27:11 raspberrypi pipedald[608]: Jack - Underrun count: 3
Feb 16 20:27:16 raspberrypi pipedald[608]: Web Socket Address: 127.0.0.1:80
Feb 16 20:27:17 raspberrypi pipedald[608]: WebSocketSession opened. ([::ffff:127.0.0.1]:53128)
Feb 16 20:27:35 raspberrypi pipedald[608]: Audio stopped.
Feb 16 20:27:36 raspberrypi pipedald[608]: Audio started.
Feb 16 20:27:45 raspberrypi pipedald[608]: WebSocketSession closed.
Feb 16 20:27:45 raspberrypi pipedald[608]: WebSocketSession opened. ([::ffff:127.0.0.1]:44198)

The sound passes through very distorted (totally useless) but I can hear the reverb effect (I did load an l2v reverb) over the heavy distorted, rather high-pitched, "metalic" sound. This is with the UGM192 soundcard.

[EE1977]

Switching back to my Focusrite Scarlett 2i2, the Pipedal system works absolutely flawlessly. Excellent response, exceptional, non-discernible latency, and overall stability.

[rerdavies]

The log files seem to say that everything's working properly - the audio cards got initialized properly, and aren't under-running.

Could you do the following for me.

1. Try increasing the audio buffer size on the Settings/Audio Settings dialog.

The default settings are 64 bytes, 3 buffers (I think). Try 256/3. If that works, you can try smaller buffer sizes to get lower latency.

2. Try connecting using a USB 2.0 port instead of a USB 3.0 port (if you are not already)

USB 3.0 ports are the two blue ports on the left. Connect the audio card to the USB 2.0 port, and connect the keyboard and mouse on the USB 3.0 ports.

3. Provide me with information on the audio card configuration as reported by ALSA.

I just added code to dump this information to the log files, but this time we'll have to do it manually.

Make sure pipedal is up and running.

The actual directory name varies depending on the sound card. Execute the following command to figure out what your sound card is called.

ls /proc/asound

I get the following results:

card0  card2  cards    Headphones  M2       oss  seq     vc4hdmi0  version
card1  card3  devices  hwdep       modules  pcm  timers  vc4hdmi1

where "M2" is the name of my current soundcard. I'm guessing you should see UGM192 or something similar.

At a bash prompt, type

cat /proc/asound/UGM192 /pcm0p/sub0/hw_params

adjusting the UGM192 part as necessary, and let me know what the results are. I'm particularly interested in what the "format:" setting is. But you may as well give me the rest as well.

[EE1977]

I am alreadu on USB 2 but also tried usb3 with same result.

card0 card2 cards Headphones modules pcm timers vc4hdmi0 version
card1 card3 devices hwdep oss seq UGM192 vc4hdmi1

[EE1977]

cat: /proc/asound/UGM192: Is a directory
cat: /pcm0p/sub0/hw_params: No such file or directory

[EE1977]

by the way, I forgot to say that I have tried several buffer settings with no result. the issue persists, whatever the buffer is.

[rerdavies]

Appologies. I accidentally added an extra space. The correct command is:

cat /proc/asound/UGM192/pcm0p/sub0/hw_params

Please try that.

[EE1977]

access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 64
buffer_size: 256

[EE1977]

my Focusrite Scarlett info is below, just for your reference.

access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 64
buffer_size: 256

[rerdavies]

Please download and install v1.0,19 of PiPedal, which corrects the following issue:

• Incorrect decoding of 24-bit-3LE audio streams.

Please let me know if resolves the issue for you so that I can close the problem report.

[EE1977]

Yes! This definitely, solves the issue. Now, the sound is at its best. Transparent, clean, and undistorted. However, I noticed a little bit more latency, but.. may this have to do with the soundcard itself?? Also, a mute switch and a master volume control, readily accessible on the app's front panel would be a nice add-on. Thanks for helping!!

[rerdavies]

Thank you for your patience, and assistance working through the problem.

I'll add a feature request for volume control, mute and VU meters on the input and out nodes.

With respect to latency, there's some reason to think that the systems that you might be able to select a smaller buffer size on the cards that weren't working. USB-audio likes audio that is in packets that are a multiple of 48 bytes; and the cards you had problems with were using 3-byte samples instead of 4-byte samples, so buffers will always be a multipe of 48 bytes.

In practice it's impossible to pre-calculate what actual latency is. There are all sorts of hidden delays in the complete audio path from input jack to output jack due to buffering by the host OS and the audio card itself.

The PiPedal distro does include a utility to measure actual latency by measuring the actual delay between audio sent on the output jack to audio received on the input jack via a looped back cable. See

https://rerdavies.github.io/pipedal/AudioLatency.html#:~:text=pipedal_latency_test

If you were interested in running the test against your UGM192 device, I'd be interested in seeing what results you get, both to satisfy my curiosity, and to confirm that there are no obvious software issues. Results at 48kHz sampling rate would be of most particular interest.

In the meantime, I'll go ahead and close this problem report.