Risultati da 1 a 2 di 2
  1. 8 kHz (mono)
    Data Registrazione
    Oct 2019
    Località
    Ancona
    Messaggi
    1
    Ringraziamenti
    0
    4th October 2019,  13:29
    1

    Jackd netmanager con rpi, possibili ottimizzazioni?

    Buongiorno a tutti e complimenti per l'elevato livello che vedo nelle discussioni.

    Opero in ambito scientifico (sono informatico, esperto di linux e faccio attività di campionamento dati in molteplici contesti) e per esigenze di ricerca sto allestendo un sistema di campionamento audio così composto:

    AudioSender:
    - RPi3 con audio usb Scarlet 2i2
    - Acquisizione su singolo canale a 192kSps
    - OS: Raspbian buster, kernel 4.19.57-v7+

    Receiver:
    - PC i7 con ubuntu 16.04
    - Onboard audio (rate massimo 48kSps)
    - software per analisi dello spettrogramma (baudline)
    - cuffie per ascolto
    - memorizza gli audio ricevuti in wav da 10minuti

    I due sono interconnessi con ethernet 100Mbps (testata a 94Mbps).

    Il sistema, che deve funzionare continuativamente h24 per settimane, per un campionamento e deve garantire la migliore qualità di acquisizione e anche se è previsto un ascolto in "realtime" l'eventuale ritardo di ricezione non costituisce problemi.

    In fase di test la configurazione è la seguente:

    Su AudioSender
    Codice:
    # jackd -r -dalsa -dhw:1 -r192000 -p 1024 -C -n3 &
    # jack_load netmanager

    Su Receiver
    Codice:
    $ jackd -d net

    Dopo il pairing tra i due, su AudioSender effettuo la connessione:
    Codice:
    # jack_connect system:capture_1 raspberry:to_slave_1
    Con questo riesco già ad utilizzare il software per la visualizzazione di spettrogramma (baudline_jack)

    Per ovviare alla necessità di ascoltare il segnale che perviene da AudioSender sulle cuffie presenti su Receiver utilizzo:
    Codice:
    $  alsa_out -dhw:PCH -r48000 -p256 -n3
    Quindi con qjackctl effettuo i collegamenti necessari per ascoltare tutto.


    Con questa configurazione il sistema funziona, ho però alcuni xrun (diminuti passando da -p 256 a -p 1024 su AudioSender), ma in particolare ho un verboso output di alsa_out del tipo:

    Codice:
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128
    delay = -128

    Premesso che in fase di produzione abbiamo intenzione di dotare anche Receiver di una scarlet 2i2 per poter riprodurre il flusso audio sulle cuffie a 192kSps senza dover ricodificare tutto a 48k (che è il massimo che supporta l'attuale scheda integrata) mi piacerebbe avere delle opinioni sulla configurazione.

    La RPi non soffre eccessivamente per il carico di jackd, che raggiunge al massimo il 20% della cpu.
    Sul Receiver ho un carico del DSP che arriva al massimo al 20%.

    Come posso scongiurare il rischio di Xrun?

    Facendo delle prove in una circostanza (e non so come è successo) ho iniziato a ricevere un suono molto metallico (usavo per test delle musiche che giungevano molto distorte).
    Riavviando la RPi è tutto svanito, ma riavviando jackd il problema persisteva. Qualcuno ha idea di cosa può essere successo e se c'è un modo per prevenirlo e/o ripristinare via software?

    Abbiamo intenzione, se i test vanno in porto con successo e se procediamo all'adozione di questo sistema, di preparare un articolo scientifico (risulta innovativo nel nostro ambito di ricerca), per chi ha modo di darci un significativo contributo c'è spazio per essere citato anche come autore.
    Ultima modifica di rocco; 4th October 2019 alle 13:31

  2. 44,1 kHz (24bit) L'avatar di SaMe
    Data Registrazione
    Apr 2014
    Località
    Avellino
    Messaggi
    2,269
    Ringraziamenti
    337
    6th October 2019,  11:18
    2

    Ciao e benvenuto,

    Così su due piedi potrebbe essere un fallimento nel driver ALSA della Pi anche se non sembrano esserci problemi nella configurazione, almeno non lato user.

    - Hai modo di fare prove su PC per vedere se hai gli stessi problemi anche su quella piattaforma?
    - Sicuro di aver bisogno dei 192ksPs? Sarebbe possibile per te fare una prova dimezzando la freq di campionamento? Potrebbe essere che la Pi pur non avendo un grosso carico in CPU non riesce lo stesso a gestire il carico di lavoro.


    Vado leggermente OT
    Probabilmente un dispositivo embedded come una STM32 F7 potrebbe essere più adatto però richiederebbe un lavoro molto maggiore.
    homo faber ipsius fortunae

Tag per Questa Discussione