Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Thread Closed 
Upcoming moOde 7.2.0 release
#11
It looks like the limit is compiled into the the loopback driver, but can be changed at compile time.

   https://alsa-user.narkive.com/ZeBRKkwU/a...-in-384khz

However, as the higher sample rate probably isn't needed by the loopback device in this case (visualisation), it might be possible to use a custom ALSA configuration file to change the sample rate after the duplication at "multi" and before the audio is passed to the loopback device (I am not sure why plughw doesn't do this) using a "rate" or "plug" plugin.

   https://www.alsa-project.org/alsa-doc/al...ugins.html

Adrian.
#12
That might be possible.

I see in the sources where the 192k rate limit is specified.

https://github.com/raspberrypi/linux/blo...rs/aloop.c
Code:
static const struct snd_pcm_hardware loopback_pcm_hardware =
{
    .info =        (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP |
             SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE |
             SNDRV_PCM_INFO_RESUME),
    .formats =    (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
             SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |
             SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |
             SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE |
             SNDRV_PCM_FMTBIT_FLOAT_LE | SNDRV_PCM_FMTBIT_FLOAT_BE),
    .rates =    SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_192000,
    .rate_min =        8000,
    .rate_max =        192000,
    .channels_min =        1,
    .channels_max =        32,
    .buffer_bytes_max =    2 * 1024 * 1024,
    .period_bytes_min =    64,
    /* note check overflow in frac_pos() using pcm_rate_shift before
       changing period_bytes_max value */
    .period_bytes_max =    1024 * 1024,
    .periods_min =        1,
    .periods_max =        1024,
    .fifo_size =        0,
};

I suppose it could be modified and compiled using our existing module compile process but then we are stuck with maintaining another custom driver.

The best way to do this would be for someone to submit a PR to the Raspberry Pi Linux kernel with the appropriate modifications to increase the rate limit to 384K. I don't see why it wouldn't be accepted given that they have already accepted many other driver mods that involve rate increases.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
#13
Hi Tim

Using "hw:Loopback" rather than "plughw:Loopback" in the ALSA configuration is working for me using a SoX rate of 384K

In /etc/alsa/conf.d/_sndaloop.conf

Code:
...
    b { channels 2 pcm "hw:Loopback,0" }    # Loopback output
...


Adrian.
#14
I'll test, thx
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
#15
It does avoid the ALSA open error but it forces the output rate to 192K. Overall though its better than having an ALSA error and no playback so I'll plan to make the change.

Ideally though someone will submit a PR to Pi Linux to bump the rate from 192K to 384K for snd-aloop driver.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
#16
Here's latest draft release notes.

We managed to fix some of the UPnP cover art issues and clean up the config screen :-)

-Tim

Code:
########################################################
//
// 2021-MM-DD TC moOde 7.2.0
//
########################################################

New features

- NEW: ALSA routing and loopback option

Radio stations

- NEW: ByteFM
- UPD: Ancient FM - Mediaeval and Renaissance Music
- UPD: BBC 128K stations
- UPD: WKCR 89.9 FM

Updates

- UPD: Show Quick Convolution filter friendly name in Audio info
- UPD: Revert the "Artist +" library option (not useful)
- UPD: Allo Boss2 OLED display script and startup
- UPD: Enhance I2S configuration to support more devices
- UPD: CamillaDSP: Show encoding of wave file
- UPD: CamillaDSP: Improved wave file converter
- UPD: Drop UAC2 fix (not applicable anymore)
- UPD: Drop UPnP Tidal/Qobuz from Config (doesn't work anymore)

Bug fixes

- FIX: Wlan_country param missing from auto-config export
- FIX: Wrong squeezelite compile in release image
- FIX: Genre data for several radio stations
- FIX: Capitalization and terminology in Audio info
- FIX: CamillaDSP: Save not disabled when other DSP active
- FIX: CamillaDSP: Config dropdown not disabled when other DSP active
- FIX: CamillaDSP: Relative paths on first use of config
- FIX: CamillaDSP: Wave file converter doesn't support floats
- FIX: CamillaDSP: Work around bug in yaml parser
- FIX: Typo in sysinfo output for throttled state
- FIX: Several issues with UPnP config and cover art
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
#17
occasionally I experience a longer power break, and the UPS goes to low battery, shutting down all services connected to UPS MONITOR. When power come back, and all services come back, I having problems with my library (NAS), it wont re-mount automatically, requiring a manual intervention.

The problem is the RPI starts quickly, and be ready before the NAS, with cause problems to reconnect the SMB path.

It could be nice to auto-mount or re-mount NAS library if it is offline, and start a update library process after that. a trigger with 5 minutes delay could check if library is mounted and if not, try to mount and update library.
#18
(04-17-2021, 01:04 PM)oculto Wrote: occasionally I experience a longer power break, and the UPS goes to low battery, shutting down all services connected to UPS MONITOR. When power come back, and all services come back, I having problems with my library (NAS), it wont re-mount automatically, requiring a manual intervention.

The problem is the RPI starts quickly, and be ready before the NAS, with cause problems to reconnect the SMB path.

It could be nice to auto-mount or re-mount NAS library if it is offline, and start a update library process after that. a trigger with 5 minutes delay could check if library is mounted and if not, try to mount and update library.

You could perhaps examine this: http://moodeaudio.org/forum/showthread.php?tid=2344
----------------
Robert
#19
(04-11-2021, 02:40 PM)adrii Wrote: Hi Tim

Using "hw:Loopback" rather than "plughw:Loopback" in the ALSA configuration is working for me using a SoX rate of 384K

In /etc/alsa/conf.d/_sndaloop.conf

Code:
...
   b { channels 2 pcm "hw:Loopback,0" }    # Loopback output
...


Adrian.

Hi Adrian, hi Tim,
over the last few weeks I have been testing the configuration via "loopback" and would like to share a couple of interesting points with you:
1. I confirm that with "hw:" instead of "plughw:" the SoX can run up to 192K.
2. The bad news is that if mpd_oled is configured as a service there is a problem: it seems that a "music play" or "radio play" must be started before mpd_oled to get the whole chain to work. It may be that with the new configuration (7.2) this is not true: I am unable to test it. My tests were carried out:
a. without any changes to playerlib (using alsaequal)
b. by editing playerlib and asound.conf.
Obviously all the tests were performed with the scratch 7.1.0 configuration.
Please let me know if and how I could help in any direction.
Sincerely and thanks,

Francesco
#20
Hi Francesco

I recently added a change to the mpd_oled service to wait for MPD to run before starting mpd_oled. This may help with the issue you are seeing.

Adrian.


Forum Jump: