diyAudio

diyAudio (https://www.diyaudio.com/forums/index.php)
-   PC Based (https://www.diyaudio.com/forums/pc-based/)
-   -   using a Raspberry Pi 4 as a USB DSP-DAC (https://www.diyaudio.com/forums/pc-based/341590-using-raspberry-pi-4-usb-dsp-dac.html)

phofman 23rd August 2019 05:37 AM

I still do not see the equivalency of usb-audio and usb-ethernet. The audio function can be used by any player, it is a regular soundcard. The ethernet function requires a very different playback chain involving some network streaming tool. Its only advantage compared to regular ethernet/network card is the separate segment with automatic IP configuration.

Back to the usb-audio gadget.

Async output should have the feedback endpoint http://dl.project-voodoo.org/usb-aud...20%20final.pdf ch. 4.10.2. That is obvious, async stream without feedback is not async. But why does the gadget define the output endpoint as asynchronous in the first place? There is no independent clock involved. When the amount of data transfered to the gadget from the host reaches the alsa device period size, the gadget will call the alsa method snd_pcm_period_elapsed which is an IRQ callback by a regular soundcard (IRQ is thrown by the soundcard when its DMA pointer reaches the boundary of period in the RAM buffer - the very same behaviour)

linux/u_audio.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub
linux/u_audio.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub

Therefore the timing fully depends on the data rate controlled by the USB host - the adaptive mode.

IMO if the output endpoint was defined as adaptive, it could work properly. A simple change

fullspeed out endpoint descriptor:
linux/f_uac2.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub

USB_ENDPOINT_SYNC_ASYNC -> USB_ENDPOINT_SYNC_ADAPTIVE

highspeed out endpoint descriptor:
linux/f_uac2.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub

USB_ENDPOINT_SYNC_ASYNC -> USB_ENDPOINT_SYNC_ADAPTIVE

Perhaps some adaptive clock lock delay should be defined (it cannot hurt):
https://github.com/torvalds/linux/bl.../f_uac2.c#L299

.bLockDelayUnits = 0,
.wLockDelay = 0,

to 1 millisecond

.bLockDelayUnits = 1,
.wLockDelay = 1,

Unfortunately I do not have a way to test it. It would involve only recompiling the kernel for RPI with these trivial changes. lsusb -v will show if the change worked. IMO it could fix the windows driver problem.

CharlieLaub 23rd August 2019 01:21 PM

Quote:

Originally Posted by phofman (https://www.diyaudio.com/forums/pc-based/341590-using-raspberry-pi-4-usb-dsp-dac-post5893255.html#post5893255)
I still do not see the equivalency of usb-audio and usb-ethernet. The audio function can be used by any player, it is a regular soundcard. The ethernet function requires a very different playback chain involving some network streaming tool. Its only advantage compared to regular ethernet/network card is the separate segment with automatic IP configuration.

Back to the usb-audio gadget.

Async output should have the feedback endpoint http://dl.project-voodoo.org/usb-aud...20%20final.pdf ch. 4.10.2. That is obvious, async stream without feedback is not async. But why does the gadget define the output endpoint as asynchronous in the first place? There is no independent clock involved. When the amount of data transfered to the gadget from the host reaches the alsa device period size, the gadget will call the alsa method snd_pcm_period_elapsed which is an IRQ callback by a regular soundcard (IRQ is thrown by the soundcard when its DMA pointer reaches the boundary of period in the RAM buffer - the very same behaviour)

linux/u_audio.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub
linux/u_audio.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub

Therefore the timing fully depends on the data rate controlled by the USB host - the adaptive mode.

IMO if the output endpoint was defined as adaptive, it could work properly. A simple change

fullspeed out endpoint descriptor:
linux/f_uac2.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub

USB_ENDPOINT_SYNC_ASYNC -> USB_ENDPOINT_SYNC_ADAPTIVE

highspeed out endpoint descriptor:
linux/f_uac2.c at 6f0d349d922ba44e4348a17a78ea51b7135965b1 * torvalds/linux * GitHub

USB_ENDPOINT_SYNC_ASYNC -> USB_ENDPOINT_SYNC_ADAPTIVE

Perhaps some adaptive clock lock delay should be defined (it cannot hurt):
https://github.com/torvalds/linux/bl.../f_uac2.c#L299

.bLockDelayUnits = 0,
.wLockDelay = 0,

to 1 millisecond

.bLockDelayUnits = 1,
.wLockDelay = 1,

Unfortunately I do not have a way to test it. It would involve only recompiling the kernel for RPI with these trivial changes. lsusb -v will show if the change worked. IMO it could fix the windows driver problem.

I have the Pi 4 and can make some time to test this out. I will send you a PM about it.

CharlieLaub 23rd August 2019 05:41 PM

1 Attachment(s)
phofman: lsusb output is in the attached file.

CharlieLaub 23rd August 2019 06:15 PM

1 Attachment(s)
More output for debugging...

CharlieLaub 23rd August 2019 06:17 PM

phofman:

Code:

charlie@ZBOX-CI329-1:~$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 2: ALC892 Alt Analog [ALC892 Alt Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Gadget [Linux USB Audio Gadget], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


CharlieLaub 23rd August 2019 06:20 PM

When I check the device parameters, the sample rate is not correct. I set up c_srate=96000 as an option when the g_audio module is loaded on the Pi, but on the Linux host the rate is shown as 48000:

Code:

charlie@ZBOX-CI329-1:~$ arecord -D hw:2,0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:2,0":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 48000
PERIOD_TIME: [1000 2730667)
PERIOD_SIZE: [48 131072]
PERIOD_BYTES: [192 524288]
PERIODS: [2 1024]
BUFFER_TIME: [2000 5461334)
BUFFER_SIZE: [96 262144]
BUFFER_BYTES: [384 1048576]
TICK_TIME: ALL
--------------------
arecord: set_params:1299: Sample format non available
Available formats:
- S16_LE


phofman 23rd August 2019 06:32 PM

OK, first let's disable the whole capture part. We need playback part from the host POW, aplay on the host (arecord on the PI4), param p_srate.

phofman 23rd August 2019 06:37 PM

You have it in my PM, set c_chmask to zero. Please post here modinfo MODULENAME.ko so that we see the actual param names.

CharlieLaub 23rd August 2019 07:00 PM

So far, I am only able to get silence. I used gstreamer pipelines on both sides. It has a built in tone generator. Both pipelines appear to be running fine, etc. but no sound comes out.

I had set the bit depth to 32 bits on the Pi. AM now trying 16 bits.

OK, that doesn't produce sound either. Hmmmm.

Tfive 23rd August 2019 07:31 PM

I wonder why you go the gstreamer route when there is a windows soundcard driver with RTP support available: GitHub - duncanthrax/scream: Virtual network sound card for Microsoft Windows

Using pulseaudio with an RTP sink on the RPi side would simplify the whole setup even more... just my 2ct.


All times are GMT. The time now is 10:18 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 17.65%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Copyright ©1999-2020 diyAudio

Wiki