Hilfestellung bei sox-Konfiguration über alsa gesucht

Musikwiedergabe über PC und Mac

Hilfestellung bei sox-Konfiguration über alsa gesucht

Beitragvon Buschel » 09.09.2018, 10:53

Hallo zusammen,

bisher habe ich über den Thread DSP - Best Practice bei Formatumwandlung und Faltung? leider keine Lösung für mein Problem gefunden. Daher gehe ich jetzt den Weg über diesen dedizierten Thread.

Ich würde gerne mit Sampleratekonvertierung über sox (anstatt der in meinem DAC integrierten) experimentieren. Bisher scheitere ich an der Anbindung über alsa. In meinem jetzigen Setup läuft die Faltung über brutefir mit der fest eingestellten Samplingfrequenz von 44,1 kHz. Dabei gibt brutefir über ein alsa-device an USB-Audio aus, und nimmt Daten über zwei alsa-devices an. Das eine alsa-device ist mit USB-Audio verbunden, das andere ist ein sogenanntes "alsa loopback" device, an das mein Softwareplayer (kodi) angeschlossen ist.

Mein Ziel ist es, brutefir und den USB-DAC mit 96 kHz laufen zu lassen. Für USB-Audio ist dies einfach umsetzbar, da der gesamte USB-Audio Pfad einfach darauf konfiguriert wird. Aber wie wandle ich die von kodi kommenden Daten (typischerweise 44,1 kHz) auf 96 kHz um? Ich hoffe, dass ihr mir hierbei ein wenig Hilfestellung geben könnt. Kann ich die Sampleratenkonvertierung per sox-SRC in eines der vorhandenen alsa-devices einbinden? Oder muss ich ein neues alsa-device definieren und dem loopback device vorschalten?

Als Referenz hier noch die aktuelle alsa Konfiguration mit
- "usbaudio" = USB-Audio in/out
- "aloopp" = alsa loopback playback (kodi gibt hierhin die Daten aus)
- "aloopc" = alsa loopback capture (brutefir holt hier die Daten von kodi ab)
- ""brutefir_44k1_32b" = dmix device, um kodi zu korrekten Auswahlmöglichkeit zu bringen

#
# USB audio (DAC)
#
pcm.usbaudio {
   type hw
   card 2
   device 0
   format S32_LE
   channels 2
}

#
# ALSA loopback (capture/playback)
#
pcm.aloopc {
   type hw
   card Loopback
        device 1
   format S32_LE
   channels 2
}

pcm.aloopp {
   type hw
   card Loopback
        device 0
}

# KODI needs "dmix" to list both brutefir devices
pcm.brutefir_44k1_32b {
   type dmix
   ipc_key 1024
   slave {
      pcm "aloopp"
      format S32_LE
      rate 44100
      period_size 512
      buffer_size 8192
   }
}

#
# Default (TV HDMI)
#
pcm.!default {
   type hw
   card 0
   device 3
}

ctl.!default {
   type hw
   card 0
   device 3
}


Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 659
Registriert: 12.12.2013, 21:12
Wohnort: Raum Karlsruhe

Beitragvon Daihedz » 10.09.2018, 23:08

Hallo Andree

Die .asoundrc ist für mich nach wie vor ein Buch mit fünf relativen Siegeln, und dennoch, einiges habe ich damit schon zum Laufen gebracht. Schau vielleicht in den Faden "Software Experimente mit Linux" hinein, dort habe ich ein (schon überholtes) Beispiel eingestellt, wie mittels einer .asoundrc eine Pipe gestartet werden könnte, welche in etwa das leisten könnte, was Dir vorschwebt. Hier ein Beispiel eines Auszugs einer etwas aktuelleren, funktionalen .asoundrc:

pcm.Audio_out_piped {
   type file
   file "| sox -b 16 -c 2 -D -e signed-integer -q -r 44100 -t raw - -b 64 -c 2 -e float -t raw - | \
   resample_soxr --band-width=91.09 --buffer-length=8192 --channels=2 --inrate=44100 --outrate=96000 --phase=25 --volume=0.75 --verbose | \
   brutefir -nodefault /home/privat/_brutefir/Cabasse/brutefir_config_cabasse | \
   volrace --buffer-length=8192 --volume=1.3 --max-volume=2.0 --verbose | \
   volrace --buffer-length=8192 --fading-length=24000 --param-file=/home/privat/_frankl/volrace.save --verbose | \
   sox -b 64 -c 2 -D -e float -q -r 96000 -t raw - -b 32 -c 2 -e signed-integer -t raw - | \
   playhrt --device=Analog_out_96000 --hw-buffer=512 --loops-per-second=1500 --max-bad-reads=100000 --mmap --non-blocking-write --number-channels=2 --sample-format=S32_LE --sample-rate=96000 --sleep=1000000 --stdin" ;
   format "raw"
   slave {
      pcm null
   }
}

### COMMON ###
pcm.null {
   type null
}


Die Funktionalität dieses .asoundrc-Moduls steht und fällt natürlich mit der Voraussetzung, dass kodi am Ausgang stets und ausschliesslich 16/44100 ausgibt.

Da mir diese Lösung etwas allzu unflexibel erschien (es macht bei wechslenden sampling rates z.B. keinen Sinn, 96kHz nach 96kHz zu konviertieren), habe ich stattdessen ein bash-script geschrieben. Damit kann ich unterschiedliche Eingangsformate bestmöglichst verarbeiten. Ich habe darin zwar (noch) kein kodi implementiert. Aber es ist beim aktuellen Stand der Dinge immerhin schon fähig, entweder eine wav-Datei beliebigen Formats einzulesen, oder aber sich auch (mittels einer dedizierten, separaten SPDIF/AES - Input-Soundkarte) automatisch auf einen potenziell stets wechselnden SPDIF-Input zu reagieren, und 44.1kHz/16, 48kHz/16 oder auch 96kHz/24 einzulesen. Brutefir faltet immer bei/mit 96kHz/64Bit, ausgegeben wird immer mit 96kHz/32Bit: Die Input-Soundkarte hat taktet somit unterschiedlich, die Output-Soundkarte immer gleich bei 96kHz.

Eine automatische Adaptation auf wechselnde In-Samplingraten setzt voraus, dass das Format des eingehenden Signals irgedwie aus Variablen für das script einlesbar ist. Das ist bei wav-Dateien aus deren Infos im header gegeben, und bei der RME9632, welche bei mir als SPDIF-Eingangsteil dient, aus dem kernel interface (/proc/asound/card[0...9]/... gegeben. Bei kodi weiss ich hingegen (noch) nicht, wie und wo das Format auszulesen wäre, da ich kodi bislang nicht ausprobiert habe.

Last not least: Für die sample-rate Konversion würde ich ausschliesslich das von frank(l) geschriebe Programm resample_soxr verwenden, und nicht etwa sox. Denn resample_soxr rechnet tiefer als sox.

Scriptophile Grüsse
Simon
Bild
Daihedz
Aktiver Hörer
 
Beiträge: 651
Registriert: 25.06.2010, 15:09

Beitragvon frankl » 11.09.2018, 01:02

Hallo Andree,

ich habe nie kodi benutzt und nur gelegentlich auf meinem Notebook mit den ALSA Konfigurationen gespielt.

Solltest Du nicht mit ALSA und einem Device

... {
   type rate
   converter samplerate_best
   ...
}


schon eine recht gute Samplerate-Konversion bekommen?

Wenn Du ein externes Programm verwenden willst (sox, resampler_soxr?) musst/kannst Du wohl ein Plugin vom 'type file' wie in Simons Beispiel verwenden (wenn das Programm mit "|" beginnt, dann wird eine Pipe geöffnet). In dem Programmtext kannst Du dann etwa '%b' und '%r' verwenden für die aktuelle Bittiefe und Samplerate (suche nach 'Plugin: file' in der ALSA Dokumentation).

Aber das war Dir vermutlich eh schon klar.

Viele Grüße,
Frank
Bild
frankl
Aktiver Hörer
 
Beiträge: 403
Registriert: 20.01.2013, 02:43
Wohnort: Aachen

Beitragvon Buschel » 11.09.2018, 06:48

Hallo Frank, Simon,

vielen Dank schon mal für eure Hinweise. Ich schaue mal, ob ich kodi zu einer pipe-Ausgabe bewegen kann, und werde ansonsten das „rate“-device ausprobieren. Ich würde allerdings gerne die Möglichkeiten von sox nutzen.

Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 659
Registriert: 12.12.2013, 21:12
Wohnort: Raum Karlsruhe

Beitragvon Buschel » 16.09.2018, 11:17

Hallo zusammen,

kurzes Zwischenfazit: Der einfache Weg über die SRC innerhalb alsa scheint zu funktionieren. Ich sehe auch unterschiedliche CPU loads, wenn ich zwischen "samplerate" und "samplerate_best" wechsele und per aplay abspiele. Bei Verwendung von kodi sehe ich allerdings keinen Unterschied und bin mir auch nicht 100%ig sicher, ob kodi wirklich weiterhin in 44,1 kHz ausgibt und alsa die SRC rechnet, oder ob kodi die SRC rechnet und direkt 96 kHz ausgibt. Sicherheit bekomme ich nur über aufwändige Mitschnitte von wav-Dateien mit Sweepsignalen, zu denen ich mich gerade nicht motivieren kann. Ich genieße deswegen erstmal weiter mit dem 44,1 kHz Setup und entspanne mich lieber. :cheers:

Trotzdem nochmal vielen Dank für die Tipps. Das Thema verfolge ich weiter.

Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 659
Registriert: 12.12.2013, 21:12
Wohnort: Raum Karlsruhe


Zurück zu Computer-HiFi

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste