axfer-transfer - Übertrager des Audiodatenrahmens für Audiogeräte und Knoten.
axfer transfer direction [ common-options ] [ backend-options ] [ filepath ]
axfer transfer direction [ common-options ] [ backend-options ] -I | --separate-channels filepath ...
direction = capture | playback
common-options = ( read OPTIONS section )
backend-options = ( read OPTIONS section )
filepaths = ( read OPTIONS section )
Der Unterbefehl transfer von axfer führt die Übertragung von Audiodatenrahmen für Geräte durch, die in unterstützten Backends verfügbar sind. Dieses Programm ist im Wesentlichen darauf ausgelegt, alsa-lib-APIs (libasound-Backend) zu verwenden, um Soundgeräte zu verwalten, die vom Linux-Sound-Subsystem (ALSA) unterstützt werden.
Dient zur Erfassungsübertragung.
Dient zur Wiedergabeübertragung.
Der Dateipfad wird als Pfad relativ zum aktuellen Arbeitsverzeichnis der Laufzeit behandelt, wenn es sich nicht um den vollständigen Pfad vom Stammverzeichnis handelt.
Die Standardeingabe oder -ausgabe wird verwendet, wenn der Dateipfad nicht angegeben oder als '-' angegeben ist.
Für die Wiedergabeübertragung wird das Containerformat des angegebenen Dateipfads automatisch erkannt und Metadaten werden für Parameter wie Beispielformat, Kanäle, Rate und Dauer verwendet. Wenn nichts erkannt wird, wird der Inhalt des angegebenen Dateipfads als Rohdaten behandelt. In diesem Fall sollten die Parameter als Optionen angegeben werden.
Mit -I | sind mehrere Dateipfade zulässig --separate-channels Option. In diesem Fall ist die Standardeingabe und -ausgabe nicht verfügbar. Derselbe Dateipfad ist nicht zulässig, außer für die unten aufgeführten Pfade: - /dev/null - /dev/zero - /dev/full - /dev/random - /dev/urandom
Hilfemeldungen drucken und Laufzeit beenden.
Ruhemodus. Nachrichten unterdrücken (kein Ton :))
Ausführlicher Modus. Die Laufzeit speichert zusätzliche Informationen entsprechend der in der Befehlszeile angegebenen Nummer dieser Option.
Unterbrechen Sie nach # Sekunden. Ein Wert von Null bedeutet Unendlich. Der Standardwert ist Null. Wenn diese Option also weggelassen wird, wird der Übertragungsprozess so lange ausgeführt, bis er abgebrochen wird. Es ist ausschließlich die Option -d oder -s verfügbar.
Unterbrechung nach der Übertragung von # Datenrahmen. Ein Wert von Null bedeutet Unendlich. Der Standardwert ist Null. Wenn diese Option also weggelassen wird, wird der Übertragungsprozess so lange ausgeführt, bis er abgebrochen wird. Es ist ausschließlich die Option -d oder -s verfügbar.
Geben Sie das Format des Audiobeispiels an. Dies ist für die Aufnahmeübertragung oder Wiedergabeübertragung mit Dateien einschließlich Rohaudiodaten erforderlich.
Das verfügbare Beispielformat ist unten aufgeführt: - [S8|U8|S16|U16|S32|U32][_LE|_BE] - [S24|U24][_LE|_BE] - FLOAT[_LE|_BE] - FLOAT64[_LE|_BE ] – IEC958_SUBFRAME[_LE|_BE] – MU_LAW – A_LAW – [S20|U20][_LE|_BE] – [S24|U24][_3LE|_3BE] – [S20|U20][_3LE|_3BE] – [S18|U18 ][_3LE|_3BE] - DSD_U8 - DSD_[U16|U32][_LE|_BE]
Wenn Endian-ness weggelassen wird, wird Host-Endian-ness verwendet.
Einige spezielle Formate sind verfügbar: - cd (16 Bit Little Endian, 44100, Stereo) [= -f S16_LE -c 2 -r 44100] - cdr (16 Bit Big Endian, 44100, Stereo) [= -f S16_BE -c 2 -f 44100] – dat (16 Bit Little Endian, 48000, Stereo) [= -f S16_LE -c 2 -r 48000]
Wenn es weggelassen wird, wird U8 standardmäßig verwendet. Die tatsächlich verfügbaren Formate werden durch jedes Übertragungs-Backend eingeschränkt.
Das nicht verfügbare Beispielformat ist unten aufgeführt. Bei diesem Format ist die Größe des Datenrahmens nicht auf die Byte-Einheit ausgerichtet.
- IMA_ADPCM - MPEG - GSM - SPEZIAL - G723_24 - G723_24_1B - G723_40 - G723_40_1B
Geben Sie die Anzahl der Audiodaten-Samples pro Frame an. Dies ist für die Aufnahmeübertragung oder Wiedergabeübertragung mit Dateien einschließlich Rohaudiodaten erforderlich. Der Wert sollte zwischen 1 und 256 liegen. Wenn es weggelassen wird, wird 1 als Standardwert verwendet.
Geben Sie die Anzahl der Audiodatenrahmen pro Sekunde an. Dies ist für die Aufnahmeübertragung oder Wiedergabeübertragung mit Dateien einschließlich Rohaudiodaten erforderlich. Wenn der Wert kleiner als 1000 ist, wird er in der Einheit kHz interpretiert. Der Wert sollte zwischen 2000 und 192000 liegen. Wenn es weggelassen wird, wird 8000 als Standardwert verwendet.
Geben Sie den Dateityp an. Dies ist für die Capture-Übertragung erforderlich. Die verfügbaren Typen sind unten aufgeführt: – wav: Microsoft/IBM RIFF/Wave-Format – au, sparc: Sparc AU-Format – voc: Creative Tech. Sprachformat – Rohdaten: Rohdaten
Wenn nichts angegeben ist, wird für die Erfassungsübertragung der Typ anhand des Suffixes filepath festgelegt und der Typ raw wird als Fallback verwendet.
Geben Sie diese Option an, wenn mehrere Dateien verarbeitet werden sollen. Wenn für die Erfassungsübertragung ein Dateipfad als filepath angegeben wird, wird eine Liste von filepaths in der Formel „
Hardware-Parameter sichern und Laufzeit beenden, wenn das Backend dies unterstützt.
Wählen Sie aus der folgenden Liste das Backend der Übertragung aus. Der Standardwert ist libasound.
- libasound - libffado (optional, wenn kompiliert)
Diese Option wird verwendet, um den PCM-Knoten im Libasound-Konfigurationsbereich auszuwählen. Verfügbare Knoten werden durch die pcm-Operation des Unterbefehls list aufgelistet.
Mit dieser Option wird der PCM-Substream im nicht blockierenden Modus geöffnet. Wenn kein Audiodatenrahmen im Puffer des PCM-Substreams verfügbar ist, kehrt der E/A-Vorgang sofort zurück, ohne dass der Prozess blockiert wird. Diese Option verwendet implizit auch die Option --waiter-type, um einen hohen CPU-Zeitverbrauch zu verhindern.
Mit dieser Option wird der Audiodatenrahmen direkt im Puffer des PCM-Substreams verarbeitet, wenn der ausgewählte Knoten diesen Vorgang unterstützt. Ohne diese Option werden temporäre Puffer verwendet, um Audiodatenrahmen für den Puffer des PCM-Substreams zu kopieren. Diese Option verwendet implizit auch die Option --waiter-type, um einen hohen CPU-Zeitverbrauch zu verhindern.
Diese Option konfiguriert den gegebenen Wert für den Hardwareparameter period_size des PCM-Substreams. Der Parameter gibt die Anzahl der Audiodatenrahmen pro Periode im Puffer des PCM-Substreams an. Die tatsächliche Anzahl wird als Ergebnis der Interaktion zwischen jeder Implementierung des PCM-Plugins, das vom ausgewählten PCM-Knoten aus verkettet ist, und In-Kernel-Treibern oder PCM-I/O-Plugins bestimmt.
Idealerweise sollte die gleiche Menge an Audiodatenrahmen wie der Wert in einem E/A-Vorgang verarbeitet werden. Tatsächlich ist dies nicht der Fall, abhängig von der Implementierung der PCM-Plugins, des In-Kernel-Treibers, der PCM-I/O-Plugins und des Planungsmodells. Für das „HW“-PCM-Plugin im „IRQ“-Planungsmodell wird der Wert verwendet, um die Intervalle der Hardware-Interrupts zu bestimmen, sodass für einen E/A-Vorgang voraussichtlich die gleiche Menge an Audiodatenrahmen verfügbar ist, wie der Wert.
Diese Option konfiguriert den gegebenen Wert für den Hardwareparameter period_time des PCM-Substreams. Diese Option ähnelt der Option --period-size, ihre Einheit ist jedoch Mikrosekunde.
Diese Option konfiguriert den gegebenen Wert für den Hardwareparameter buffer_size des PCM-Substreams. Der Parameter gibt die Anzahl der Audiodatenrahmen im Puffer des PCM-Substreams an. Die tatsächliche Anzahl wird als Ergebnis der Interaktion zwischen jeder Implementierung des PCM-Plugins, das vom ausgewählten PCM-Knoten aus verkettet ist, und In-Kernel-Treibern oder PCM-I/O-Plugins bestimmt.
Im Idealfall ist dies ein Vielfaches der Anzahl der Audiodatenrahmen pro Periode, also der Größe der Periode. Tatsächlich ist dies nicht der Fall, abhängig von der Implementierung der PCM-Plugins, des In-Kernel-Treibers und der PCM-I/O-Plugins.
Diese Option konfiguriert den gegebenen Wert für den Hardwareparameter buffer_time des PCM-Substreams. Diese Option ähnelt der Option --buffer-size, ihre Einheit ist jedoch Mikrosekunde.
Diese Option gibt den Typ des Kellners für die Ereignisbenachrichtigung an. Derzeit sind vier Typen verfügbar; default , select , poll und epoll . Beim Standard-Typ wird „snd_pcm_wait()“ verwendet. Beim Typ select wird der Systemaufruf „select(2)“ verwendet. Beim Typ poll wird der Systemaufruf „poll(2)“ verwendet. Beim Typ epoll wird der Linux-spezifische Systemaufruf „epoll(7)“ verwendet.
Diese Option sollte einer der Optionen --nonblock oder --mmap oder dem timer-Wert von --sched-model entsprechen -Option. Weder diese Option noch --test-nowait sind gleichzeitig verfügbar.
Diese Option wählt das Planungsmodell für den Prozess dieses Programms aus. Es ist entweder irq oder timer verfügbar. Im Detail lesen Sie bitte den Abschnitt „PLANUNGSMODELL“.
Wenn nichts angegeben ist, wird das irq-Modell verwendet.
Diese Option konfiguriert den gegebenen Wert für den Softwareparameter avail-min des PCM-Substreams. Im Blockierungsmodus wird der Wert als Schwellenwert für die Anzahl der verfügbaren Audiodatenrahmen im Puffer des PCM-Substreams verwendet, um den durch den E/A-Vorgang blockierten Prozess aufzuwecken. Im nicht blockierenden Modus gibt jede E/A-Operation -EAGAIN zurück, bis die verfügbare Anzahl von Audiodatenrahmen den Schwellenwert erreicht.
Diese Option hat eine Auswirkung in Fällen, in denen weder --mmap noch der timer-Wert der Option --sched-model verwendet wird.
Diese Option konfiguriert den gegebenen Wert für den Softwareparameter start_threshold des PCM-Substreams. Der Wert wird als Schwellenwert zum automatischen Starten des PCM-Substreams verwendet. Derzeit ist diese Option in Fällen wirksam, in denen weder --mmap noch der timer-Wert der Option --sched-model verwendet wird.
Wenn bei der Wiedergabeübertragung die Anzahl der akkumulierten Audiodatenrahmen im Puffer des PCM-Substreams, in den dieses Programm schreibt, den Schwellenwert erreicht, startet der PCM-Substream automatisch ohne einen expliziten Aufruf von snd_pcm_start() an den PCM Unterstrom.
Für die Capture-Übertragung ist diese Option nutzlos. Die Anzahl der akkumulierten Audiodatenrahmen wird ohne einen expliziten Aufruf von snd_pcm_start() an den PCM-Substream nicht erhöht.
Diese Option hat eine Auswirkung in Fällen, in denen weder --mmap noch der timer-Wert der Option --sched-model verwendet wird.
Diese Option konfiguriert den gegebenen Wert für den Softwareparameter stop_threshold des PCM-Substreams. Der Wert wird als Schwellenwert zum automatischen Stoppen des PCM-Substreams verwendet. Derzeit ist diese Option in Fällen wirksam, in denen weder --mmap noch der timer-Wert der Option --sched-model verwendet wird.
Wenn bei der Capture-Übertragung die Anzahl der akkumulierten Audiodatenrahmen im Puffer des PCM-Substreams, in den ein Treiber oder PCM-Plugins alsa-lib schreiben, den Schwellenwert erreicht, stoppt der PCM-Substream automatisch ohne einen expliziten Aufruf von snd_pcm_stop() zum PCM-Substream. Dies ist ein Fall, in dem dieses Programm die Audiodatenrahmen eine Zeit lang nicht liest.
Wenn bei der Wiedergabeübertragung die Anzahl der verfügbaren Audiodatenrahmen im Puffer des PCM-Substreams, aus dem ein Treiber oder alsa-lib-PCM-Plugins liest, den Schwellenwert erreicht, stoppt der PCM-Substream automatisch ohne einen expliziten Aufruf von snd_pcm_stop() zum PCM-Substream. Dies ist ein Fall, in dem dieses Programm die Audiodatenrahmen eine Zeit lang ohne Schreiben lässt.
Diese Option hat eine Auswirkung in Fällen, in denen weder --mmap noch der timer-Wert der Option --sched-model verwendet wird.
Diese Option wirkt sich auf das Plugin „plug“ in alsa-lib aus, um die Konvertierung der Abtastrate für Audiodatenrahmen zu unterdrücken.
Diese Option wirkt sich auf das Plugin „plug“ in alsa-lib aus, um die Konvertierung von Kanälen für Audiodatenrahmen zu unterdrücken.
Diese Option wirkt sich auf das Plugin „plug“ in alsa-lib aus, um die Konvertierung des Sample-Formats für Audiodatenrahmen zu unterdrücken.
Diese Option wirkt sich auf das Plugin „softvol“ in alsa-lib aus, um die Konvertierung von Samples für Audiodatenrahmen über ein zusätzliches Steuerelement zu unterdrücken.
Diese Option unterdrückt den Wiederherstellungsvorgang vom XRUN-Status des laufenden PCM-Substreams, dann wird der Prozess dieses Programms wie gewohnt abgeschlossen.
Diese Option deaktiviert jeden Waiter für E/A-Ereignisbenachrichtigungen. E/A-Vorgänge werden wiederholt, bis ein Audiodatenrahmen verfügbar ist. Die Option bringt eine hohe CPU-Zeitbelastung mit sich.
Dieses Backend ist automatisch verfügbar, wenn das Konfigurationsskript das Symbol ffado_streaming_init() im gemeinsam genutzten libffado-Objekt erkennt.
Diese Option verwendet den angegebenen Wert, um zu entscheiden, welcher 1394 OHCI-Controller für die Kommunikation verwendet wird. Wenn das Linux-System über zwei 1394 OHCI-Controller verfügt, sind 0 oder 1 verfügbar. Weder diese Option noch -g sind gleichzeitig verfügbar. Wenn nichts angegeben ist, kommuniziert libffado mit Einheiten auf dem IEEE 1394-Bus, der von allen im Linux-System verfügbaren 1394 OHCI-Controllern verwaltet wird.
Diese Option verwendet den angegebenen Wert, um zu entscheiden, welche Einheit für die Kommunikation verwendet wird. Diese Option erfordert die Option -p, um anzugeben, welcher 1394 OHCI-Controller für die Kommunikation mit der angegebenen Einheit verwendet wird.
Diese Option verwendet einen gegebenen Wert, um zu entscheiden, mit welcher Zieleinheit kommuniziert werden soll. Dem Wert sollte „0x“ vorangestellt werden und er besteht aus hexadezimalen Literalbuchstaben (0-9, a-f, A-F). Weder diese Option noch -p sind gleichzeitig verfügbar. Wenn nichts angegeben ist, kommuniziert libffado mit Einheiten auf dem IEEE 1394-Bus, der von allen im Linux-System verfügbaren 1394 OHCI-Controllern verwaltet wird.
Diese Option verwendet den angegebenen Wert, um die Anzahl der Audiodatenrahmen in einem Lese-/Schreibvorgang zu bestimmen. Der Vorgang wird blockiert, bis die Anzahl der verfügbaren Audiodatenrahmen den angegebenen Wert überschreitet. Standardmäßig werden 512 Audiodatenrahmen verwendet.
Diese Option verwendet den angegebenen Wert, um die Größe des Zwischenpuffers zwischen diesem Programm und libffado zu bestimmen. Standardmäßig werden 2 Perioden pro Puffer verwendet.
Mit dieser Option kann dieses Programm den Slave-Modus ausführen. In diesem Modus fügt libffado das Einheitenverzeichnis zum Konfigurations-ROM des 1394 OHCI-Controllers hinzu, auf dem das Linux-System ausgeführt wird. Das Einheitenverzeichnis kann von dem anderen Knoten am selben Bus gefunden werden. Das auf dem Knoten laufende Linux-System kann isochrone Pakete mit Audiodatenrahmen an das Gerät übertragen. Dieses Programm kann das Paket empfangen und den Audiodatenrahmen demultiplexen.
Mit dieser Option kann dieses Programm den Snoop-Modus ausführen. In diesem Modus überwacht libffado isochrone Kanäle, an die das Gerät isochrone Pakete überträgt. Wenn die isochrone Kommunikation von einer beliebigen Einheit am selben Bus gestartet wird, können die Pakete von diesem Programm verarbeitet werden.
Diese Option führt pthread_setschedparam() in einem Aufruf von ffado_streaming_init() aus, um die Planungsrichtlinie und den angegebenen Wert als Priorität für Threads im Zusammenhang mit isochroner Kommunikation zu konfigurieren. Der angegebene Wert sollte innerhalb des Parameters RLIMIT_RTPRIO des Prozesses liegen. Weitere Informationen finden Sie unter getrlimit(2).
Während der Übertragung schließen SIGINT und SIGTERM die verarbeiteten Dateien und den PCM-Substream, um die Laufzeit zu beenden.
SIGTSTP unterbricht den PCM-Substream und SIGCONT setzt ihn fort. Es werden keine XRUNs erwartet. Beim libffado-Backend wird das Anhalten/Fortsetzen nicht unterstützt und die Laufzeit wird sofort abgebrochen.
Die anderen Signale führen Standardverhalten aus.
$ axfer transfer playback -d 1 somethingDas Obige überträgt den Audiodatenrahmen in eine „irgendwas“-Datei zur Wiedergabe während einer Sekunde. Das Beispielformat wird als Ergebnis automatisch erkannt, um „etwas“ zu analysieren, solange es mit einem von Microsoft/IBM RIFF/Wave, Sparc AU, Creative Tech kompatibel ist. Sprachformate. Wenn nichts erkannt wird, sollten -r , -c und -f oder -f angegeben werden mit Sonderformat.
$ axfer transfer playback -r 22050 -c 1 -f S16_LE -t raw somethingDas Obige überträgt den Audiodatenrahmen in einer „etwas“-Datei, die keine Informationen zum Beispielformat enthält, als Beispielformat von 22050 Hz, monaural, vorzeichenbehaftetes 16-Bit-Little-Endian-PCM für die Wiedergabe. Die Übertragung wird fortgesetzt, bis SIGINT über die Tastatur oder SIGTERM durch kill(1) abgefangen wird.
$ axfer transfer capture -d 10 -f cd something.wavDas Obige überträgt den Audiodatenrahmen 10 Sekunden lang in die Datei „something.wav“ im Beispielformat 44,1 kHz, 2 Kanäle, vorzeichenbehaftetes 16-Bit-Little-Endian-PCM. Das Dateiformat ist Microsoft/IBM RIFF/Wave entsprechend dem Suffix des angegebenen filepath .
$ axfer transfer capture -s 1024 -r 48000 -c 2 -f S32_BE -I -t au channelsDas Obige überträgt Audiodatenrahmen als Beispielformat von 48,0 kHz, 2 Kanälen, signiertes 32-Bit-Big-Endian-PCM für 1.024 Datenrahmen in Dateien mit den Namen „channels-1.au“ und „channels-2.au“.
In einem Design des ALSA PCM-Kerns unterstützt die Laufzeit des PCM-Substreams zwei Modi; period-wakeup und no-period-wakeup. Diese beiden Modi gelten für unterschiedliche Planungsmodelle.
Standardmäßig wird der Modus period-wakeup verwendet. In diesem Modus sollten In-Kernel-Treiber die Hardware so betreiben, dass sie regelmäßige Benachrichtigungen für die Übertragung von Audiodatenrahmen generiert. Das Benachrichtigungsintervall entspricht der gleichen Menge an Audiodatenrahmen wie eine Pufferperiode, bezogen auf die tatsächliche Zeit.
In einem der Benachrichtigung zugewiesenen Handler wird eine Hilfsfunktion des ALSA PCM-Kerns aufgerufen, um eine Position zum Leiter der Hardwareübertragung zu aktualisieren und sie dann mit einer Position zum Leiter des Anwendungsbetriebs zu vergleichen, um Überlauf/Unterlauf (XRUN) zu beurteilen und aufzuwecken blockierte Prozesse.
Zu diesem Zweck wird typischerweise der Hardware-IRQ des Controllers für serielle Audiobusse wie Inter-IC-Sound verwendet. In diesem Fall generiert der Controller den IRQ entsprechend der Übertragung auf dem seriellen Audiobus. In dem dem IRQ zugewiesenen Handler wird eine DMA-Übertragung (Direct Media Access) zwischen dem dedizierten Hostspeicher und dem Gerätespeicher angefordert.
Wenn die Zielhardware diesen Mechanismus nicht unterstützt, sollte die periodische Benachrichtigung von einem beliebigen Timer emuliert werden; z.B. hrtimer, Kernel-Timer. Externe PCM-Plugins, die vom PCM-Plugin-SDK in alsa-lib generiert werden, sollten ebenfalls das oben genannte Verhalten emulieren.
In diesem Modus werden PCM-Anwendungen entsprechend der typischen Art und Weise von E/A-Vorgängen programmiert. Sie führen blockierende Systemaufrufe aus, um Audiodatenrahmen im Puffer des PCM-Unterstroms zu lesen/schreiben, oder blockierende Systemaufrufe, um zu warten, bis ein Audiodatenrahmen verfügbar ist. In axfer wird dies als IRQ-basiertes Planungsmodell und als Standardverhalten bezeichnet. Benutzer können diesen Modus explizit konfigurieren, indem sie die Option --sched-model mit dem Wert irq verwenden.
Der no-period-wakeup-Modus ist ein optionaler Laufzeitmodus des PCM-Substreams. Der Modus setzt eine bestimmte Hardwarefunktion voraus und unterstützt Kernel-Treiber und PCM-Anwendungen. In diesem Modus betreiben In-Kernel-Treiber keine Hardware, um regelmäßige Benachrichtigungen für die Übertragung von Audiodatenrahmen zu generieren. Die Hardware sollte die Übertragung des Audiodatenrahmens automatisch fortsetzen, ohne dass die Treiber regelmäßig betätigt werden müssen. z.B. Laut automatisch ausgelöster DMA-Übertragung eine Kette registrierter Deskriptoren.
In diesem Modus weckt nichts blockierte Prozesse auf, daher sollten PCM-Anwendungen ohne blockierenden Vorgang programmiert werden. Aus diesem Grund wird dieser Modus aktiviert, wenn die PCM-Anwendungen Hardwareparameter explizit für die Laufzeit des PCM-Substreams konfigurieren, um Störungen bestehender Anwendungen zu verhindern. Darüber hinaus wird die Zeitsteuerung für die Übertragung des Audiodatenrahmens durch nichts aufrechterhalten, daher sollten die PCM-Anwendungen freiwillig jeden Timer verwalten, um den Audiodatenrahmen im Puffer des PCM-Substreams für eine gewisse Zeit in die Warteschlange zu stellen. Darüber hinaus sollte die PCM-Anwendung anstelle des Treibers eine Hilfsfunktion des ALSA PCM-Kerns aufrufen, um eine Position an den Leiter der Hardwareübertragung zu aktualisieren und XRUN zu überprüfen.
In axfer wird dies als timerbasiertes Planungsmodell bezeichnet und ist verfügbar, solange Hardware/Treiber die no-period-wakeup-Laufzeit unterstützt. Benutzer sollten diesen Modus explizit festlegen, indem sie die Option --sched-model mit dem Wert timer verwenden.
Im Planungsmodell müssen PCM-Anwendungen den verfügbaren Speicherplatz im PCM-Puffer im Laufe der Zeit verwalten, typischerweise indem sie CPU freigeben und auf eine Neuplanung warten. Für die Ausbeute wird eine Zeitüberschreitung für die gewünschte Anzahl zu verarbeitender PCM-Frames berechnet. Dies ist praktisch für eine Art von Anwendungen, wie z. B. Soundserver. Wenn ein E/A-Thread des Servers auf die Zeitüberschreitung wartet, können die anderen Threads Audiodatenrahmen für Server-Clients verarbeiten. Darüber hinaus können Anwendungen durch die Verwendung von Zurückspulen/Weiterleiten eine geringe Latenz zwischen Übertragungsposition und Bearbeitungsposition erreichen, selbst wenn sie große PCM-Puffer verwenden.
Im Idealfall hat das timerbasierte Planungsmodell einige Vorteile gegenüber dem IRQ-basierten Planungsmodell. Zunächst wird kein Interrupt-Kontext für den PCM-Substream ausgeführt. Der PCM-Substream wird nur in jedem Prozesskontext verarbeitet. Es besteht keine Notwendigkeit, sich um Race-Bedingungen zwischen IRQ- und Prozesskontexten zu kümmern. Dies verringert einige Bedenken einiger Entwickler von Treibern und Anwendungen. Zweitens wird die CPU-Zeit nicht für Handler im Interrupt-Kontext verwendet. Die CPU-Zeit kann für andere Aufgaben reserviert werden. Das ist in einem Point-of-Time-Sharing-System gut. Drittens ist die Hardware nicht für die Generierung von Interrupts konfiguriert. Dies ist möglicherweise im Hinblick auf eine Reduzierung des Gesamtstromverbrauchs von Vorteil.
In beiden Planungsmodellen sollte die Hardware es den Treibern ermöglichen, die Anzahl der Audiodatenrahmen zu lesen, die zwischen dem dedizierten Speicher und dem Gerätespeicher für den seriellen Audiobus übertragen werden. Bei einem timerbasierten Planungsmodell sind jedoch eine feine Granularität und Genauigkeit des Werts wichtig. Tatsächlich übernimmt die Hardware die Übertragung zwischen dem dedizierten Speicher und dem Gerätespeicher für eine kleine Menge von Audiodatenrahmen oder Bytes. Im Hinblick auf PCM-Anwendungen ist die Granularität der aktuellen Übertragung erforderlich, um das richtige Timeout für jeden E/A-Vorgang zu bestimmen. Ab Linux-Kernel v4.21 verfügt die ALSA PCM-Schnittstelle zwischen Kernel/Userspace über keine Funktion, um dies zu melden.
Der Unterbefehl transfer von axfer soll die Kompatibilität zu aplay(1) gewährleisten. Einige der unten aufgeführten Optionen sind jedoch aus mehreren technischen Gründen nicht kompatibel.
Diese Option wird nur für Dateien zum Speichern von Audiodatenrahmen unterstützt, die jedem Kanal entsprechen. In der aplay(1)-Implementierung hat diese Option einen zusätzlichen Effekt, um den PCM-Puffer zu verwenden, der auf eine nicht verschachtelte Reihenfolge ausgerichtet ist, wenn ein Zielgerät dies unterstützt. Ab 2018 wird der PCM-Puffer nicht verschachtelter Ordnung von Audiogeräten kaum noch verwendet.
Diese Option gibt den Schwellenwert an, um den blockierten Prozess in einer Einheit Audiodatenrahmen aufzuwecken. Gegenüber der aplay(1)-Implementierung hat diese Option keine Auswirkung auf die Option --mmap sowie den timer der Option --sched-model.
Diese Option gibt den Schwellenwert an, um den vorbereiteten PCM-Substream in einer Einheit Audiodatenrahmen zu starten. Gegenüber der aplay(1)-Implementierung hat diese Option keine Auswirkung auf die Option --mmap sowie den timer der Option --sched-model.
Diese Option gibt den Schwellenwert an, um die Ausführung des PCM-Substreams in einer Einheit Audiodatenrahmen zu stoppen. Gegenüber der aplay(1)-Implementierung hat diese Option keine Auswirkung auf die Option --mmap sowie den timer der Option --sched-model.
Diese Option wird nicht unterstützt. In der aplay(1)-Implementierung wirkt sich die Option auf die Capture-Übertragung aus, um Dateien bis zur gleichen Anzahl von Datenrahmen zu speichern, wie der angegebene Wert pro Sekunde oder die maximale Anzahl von Datenrahmen, die vom verwendeten Dateiformat unterstützt wird. Wenn die Begrenzung erreicht ist, wird die verwendete Datei geschlossen, dann eine neue Datei geöffnet und Audiodatenrahmen werden geschrieben. Diese Option erfordert jedoch eine zusätzliche Handhabung von Dateien und erhöht die Komplexität der Hauptschleife von axfer.
Diese Option wird nicht unterstützt. In der aplay(1)-Implementierung wirkt sich die Option auf die Capture-Übertragung aus, um Dateipfade entsprechend dem angegebenen Format zu generieren, in dem einige zusätzliche Formate verfügbar sind sowie von strftime(3) unterstützte Formate. Allerdings erfordert diese Option eine zusätzliche Zeichenfolgenverarbeitung für Dateipfade und ist lästig, wenn sie in der Sprache C geschrieben ist.
Diese Option wird nicht unterstützt. In der aplay(1)-Implementierung bewirkt die Option, dass eine Datei für einen bestimmten Wert erstellt und die Prozess-ID darin geschrieben wird. Mit dieser Datei können Benutzer die Prozess-ID abrufen und ein beliebiges POSIX-Signal an einen Play-Prozess senden. Allerdings birgt diese Idee einige Probleme beim Sperren von Dateien, wenn mehrere Aplay-Prozesse mit derselben Datei ausgeführt werden.
Diese Option wird derzeit nicht unterstützt. In der aplay(1)-Implementierung bewirkt diese Option, dass stdout mit einigen Terminal-Steuerzeichen belegt wird und Vumeter für Mono- und Stereokanäle angezeigt werden. Es lagen jedoch einige Probleme vor; Diese Funktion gilt nur für Audiodatenrahmen im PCM-Format. Diese Funktion führt nach einem Abbruch zu einer Störung des Terminals. Standardausgabe ist für die Pipeline nicht verfügbar.
Diese Option wird derzeit nicht unterstützt. In der aplay(1)-Implementierung bewirkt diese Option, dass stdin für die Tasteneingabe belegt wird und der PCM-Substream entsprechend der gedrückten Eingabetaste angehalten/fortgesetzt wird. Diese Funktion erfordert jedoch eine zusätzliche Eingabeverarbeitung in der Hauptschleife und hinterlässt lästige Vorgänge zur Aufrechterhaltung des PCM-Unterstroms.
Der ALSA PCM-Kern und der Steuerungskern unterstützen diese Funktion nicht, daher sollte die Neuzuordnung im Userspace erfolgen. Dies bringt einen Mehraufwand für die Ausrichtung von Audiodatenrahmen mit sich, insbesondere für den MMAP-Betrieb. Darüber hinaus unterstützen einige Plugins ab alsa-lib v1.1.8 diese Funktion nicht wie erwartet, sodass diese Option einen Mangel an transparentem Betrieb darstellt. Um Benutzer nicht zu verwirren, wird diese Option derzeit noch nicht unterstützt.
Dadurch wird der PCM-Substream angehalten/fortgesetzt. In der aplay(1)-Implementierung bringen diese Vorgänge den XRUN-Status in den Substream, und das Anhalten/Fortsetzen erfolgt wie oben im interaktiven Modus. Einige Entwickler verwenden das Signal für den Wiederherstellungstest von XRUN. Derzeit wird keine Alternative für den Test unterstützt.
Dies wird nicht unterstützt. In der aplay(1)-Implementierung wird dieses Signal einem Handler zugewiesen, um eine aktuelle Datei zum Speichern des Audiodatenrahmens zu schließen und eine neue Datei zu öffnen, um die Verarbeitung fortzusetzen. Allerdings sollte diese Option, ebenso wie die Option --max-file-time, die Komplexität der Hauptschleife von axfer erhöhen.
Dieses Programm besteht aus drei Modulen; xfer , mapper und container . Jedes Modul verfügt über eine Abstraktionsschicht, um die tatsächliche Implementierung zu ermöglichen.
-------- ---------- -------------
device <-> | xfer | <-> | mapper | <-> | container | <-> file
-------- ---------- -------------
libasound single wav
libffado multiple au
voc
rawDas Modul xfer führt die eigentliche Übertragung an Geräte und Knoten durch. Das Modul kann mehrere Übertragungs-Backends haben. Als Standard-Backend wird das libasound-Backend verwendet, um die Übertragung über alsa-lib-APIs durchzuführen. Das Modul ermöglicht es jedem Backend, eigene Befehlszeilenoptionen zu analysieren.
Das Container-Modul führt das Lesen/Schreiben von Audiodatenrahmen über einen Deskriptor für Dateien/Streams von Multimedia-Containern oder Rohdaten durch. Das Modul erkennt automatisch den Typ des Multimedia-Containers und analysiert Parameter in seinen Metadaten des Datenheaders. Derzeit werden drei Arten von Multimedia-Containern unterstützt; Microsoft/IBM RIFF/Wave ( wav ), Sparc AU ( au ) und Creative Technology Voice ( voc ). Zusätzlich ist ein spezieller Container für Roh-Audiodaten vorbereitet ( raw ).
Das Mapper-Modul übernimmt das Pufferlayout und die Ausrichtung für die Übertragung von Audiodatenrahmen. Das Modul verfügt über zwei Implementierungen; single und multiple . Das einzelne Backend verwendet einen Container zum Aufbau des Puffers. Das multiple-Backend verwendet mehrere Container, um es zu erstellen.
Zwischen dem xfer-Modul und dem mapper-Modul wird ein Zeiger auf den Puffer einschließlich Audiodatenrahmen übergeben. Dieser Puffer hat zwei Formen für die verschachtelte und die nicht verschachtelte Reihenfolge. Bei ersterem zeigt der Zeiger auf einen Puffer. Bei letzterem zeigt der Zeiger auf ein Array, in dem jedes Element auf einen Puffer zeigt. Zwischen dem Mapper-Modul und dem Container-Modul wird ein Zeiger auf einen Puffer übergeben, da unterstützte Mediencontainer, einschließlich Rohtyp, Audiodatenrahmen in verschachtelter Reihenfolge speichern.
Beim Übertragen von Audiodatenrahmen zwischen den Modulen ist axfer so programmiert, dass das Kopieren zwischen einem Puffer und einem anderen Puffer so weit wie möglich vermieden wird. In einigen der folgenden Szenarien findet beispielsweise kein Kopieren zwischen Modulen statt.
- xfer(mmap/interleaved), Mapper(single), Container(any) - xfer(mmap/non-interleaved), Mapper(multiple), Container(any)
Für jedes Modul Mapper und Container ist ein Komponententest verfügbar. Um die Tests auszuführen, führen Sie den folgenden Befehl aus:
$ make testBei jedem Test wird mehrmals in die Datei geschrieben und gelesen, und es dauert lange, bis er abgeschlossen ist. Bitte achten Sie auf die Ausführungszeit, wenn Sie es in einer CI-Umgebung ausführen.
axfer(1), axfer-list(1), alsamixer(1), amixer(1)
Takashi Sakamoto