ubuntuusers.de

Ich versuche mich gerade in der Soundprogrammierung. Main Testprogramm basiert auf der Datei "pcm.c" aus den Beispielen der "ALSA library reference". Die obige Warnung bezieht sich auf folgende Zeile

1

    snd_pcm_hw_params_alloca(&hwparams);

laut Dokumentation ist das wohl ein Macro, dessen Definition ich zwar nicht finden kann, wohl aber die Beschreibung:

Define Documentation
#define snd_pcm_hw_params_alloca 	( 	ptr  		 )  	

allocate an invalid snd_pcm_hw_params_t using standard alloca

Parameters:
    	ptr 	returned pointer

Examples:
    /test/latency.c, and /test/pcm.c.

Ich kämpfe mich jetzt schon seit mehreren Tagen durch diese etwas weltfremde Dokumentation und tue mich etwas schwer damit, Mein Eindruck ist, die wollen nicht das jemand begreift was da gemacht wird.

Trotzdem muss ich da durch, wenn ich meinem 'headless' Sever beibringen möchte, seine Probleme via Morsezeichen kundzutun (bisher war das recht einfach mittels Bash Script und dem Programm "Beep" möglich, was aber bei PCs ohne PC-Piepser nicht mehr geht und ich mich deshalb gezwungen sehe über die Soundkarte zu gehen).

Das von mir abgeänderte Programm tut zwar bisher was es soll, soweit man das von einem 'proove of concept' erwaten kann, aber mich stört halt jede Warnung des Compilers, insbesondere wenn ich den Grund dafür nicht nachvollziehen kann.

Deshalb hoffe ich, das mir jemand sagen kann, wie ich diese Warnung loswerden kann, oder wie ich dem Grund dafür auf die Spur kommen kann.

Servus,

Dakuan schrieb:

Mein Eindruck ist, die wollen nicht das jemand begreift was da gemacht wird.

diesen Eindruck hab’ ich leider auch manchmal.

Als was ist dein hwparams deklariert? Soweit ich weiß, sollte das ein snd_pcm_hw_params_t *params sein, was auch in der test/pcm.c so ist (zumindest in der, die ich hier gerade habe – stammend aus alsa-lib-1.0.24.1). Das Makro selbst ist definiert als (/usr/include/alsa/pcm.h in Arch Linux):

1

#define snd_pcm_hw_params_alloca(ptr) __snd_alloca(ptr, snd_pcm_hw_params)

Und das Ding wiederum (/usr/include/alsa/global.h):

1

#define __snd_alloca(ptr,type) do { *ptr = (type##_t *) alloca(type##_sizeof()); memset(*ptr, 0, type##_sizeof()); } while (0)

Was dann auch erklärt, wieso es snd_pcm_hw_params_t *params sein muss.

Grundsätzlich: Wäre vielleicht das kleine Tool aplay eine Alternative für dein Vorhaben?

diesen Eindruck hab’ ich leider auch manchmal.

Es baut mich ein klein wenig auf, zu wissen, nicht alleine zu sein 😉

Die von Dir angeführten Quellen werde ich morgen mal untersuchen. Angesichts des ersten brauchbaren Erfolges trotz ignorierens diverser Warnungen, habe ich schon ein Bier zuviel intus und bin nicht mehr in Grübellaune.

... in Arch Linux):

Ich hoffe das ich nicht auf Arch Linux zurückgreifen muss. Das habe ich zwar auch, aber da muss ich wohl erst 4 Monate Updatrückstand aufholen und ob das dann noch läuft? Mit meiner NSLU2 bin ich mir Roling Releases schonmal auf die Nase gefallen. Jedenfalls weiss ich jetzt wo ich mal suchen kann.

Übrigens, gerade die "test/pcm.c" erweckt bei mir den Eindruck, das hier ein Beispiel aus einem Großeren Programm zusammengekürzt wurde oder aber irgendwelchen praxisfremden Ideologien nachgegangen wurde. Jedenfalls würde ich nicht ohne fremde Gewaltandrohung den Speicherplatz für eine so kleine Datenstruktur wie "snd_pcm_channel_area_t" eine dynamische Memoryalozierung bemühen. Das ist übertrieben und dient nur der Verwirrung.

Wäre vielleicht das kleine Tool aplay eine Alternative für dein Vorhaben?

Nicht ganz. Ich benutze das zwar momentan übergangsweise als Notlösung, ist aber kein vollwertiger Ersatz. Ich kan damit ja nur bestimmte vordefinierte Zustände per WAV Datei signalisieren, z.B. wenn der Server gestartet ist durch das Anlassgeräusch eines alten Autos ( der Feuerwehrtruck aus "Running Wild" von Firehouse Five kommt da besonders gut!), aber damit kann ich keine Fehler- oder Statusmeldungen ausgeben wie beispielsweise eine Temberaturwarnung oder die Meldung, das der Server sich bei weiterer Nichtbenutzung in 5 Minuten abschalten wird (als Morsecode: QRT 5).

Aber "aplay" ist tatsächlich ein gutes Beispiel aus der Praxis. Zeigt es doch dass es auch etwas schlanker geht. Ich experimentiere seit einiger Zeit mit WAV Dateien und das ermuntert mich, die Schnittpunkte meiner Dateien irgendwann nicht nur per Zeitcode sondern auch akkustisch darzustellen.

Bei mit ist das Macro komplett in /usr/include/alsa/pcm.h definiert:

1

#define snd_pcm_hw_params_alloca(ptr) do { assert(ptr); *ptr = (snd_pcm_hw_params_t *) alloca(snd_pcm_hw_params_sizeof()); memset(*ptr, 0, snd_pcm_hw_params_sizeof()); } while (0)

mir kommt aber bei beiden Versionen das "while (0)" am Ende suspect vor. Ich kann momentan auch nicht wirklich nachvollziehen was da alles passieert. Am Wochenende werd ich mal versuchen, ob man das nicht durch ein simples malloc ersetzen kann. Im Quelltext vom aplay taucht das Macro übrigens nicht auf.

Dakuan schrieb:

mir kommt aber bei beiden Versionen das "while (0)" am Ende suspect vor. Ich kann momentan auch nicht wirklich nachvollziehen was da alles passieert.

Deine Version tut nichts anderes, als Platz für ein solches struct auf dem Heap zu holen (sofern ptr nicht 0 ist) und diesen Speicher mit Nullen vollzuhauen. Was die „Schleife“ da soll, verstehe ich auch nicht so ganz – vielleicht Compiler-Kompatibilität, keine Ahnung. So tief stecke ich im CPP-Krams nicht drin. ☹

Im Quelltext vom aplay taucht das Macro übrigens nicht auf.

Bei mir schon. 😮 Liegt vermutlich an der neueren Version.

Aber mal zum eigentlichen Problem: Das assert() in deiner Version des Makros ist schuld. Bei mir gibt es das nicht. Verwende ich dein Makro, bekomme ich dieselbe Warnung. Und die Warnung ist auch ziemlich logisch: Der Präprozessor ersetzt das Makro ja, sodass dort am Ende steht:

1

assert(&foo);

assert() tut im Wesentlichen nichts anderes als zu prüfen, ob die Expression in Klammern true ist. Und foo ist eine Variable auf dem Stack, deren Adresse niemals NULL sein wird, also ist der Ausdruck immer true. Folglich sagt der Compiler, dass das assert() da sinnfrei ist.

Dagegen kannst du also gar nichts tun, außer das Makro nicht zu benutzen. Dann läufst du halt Gefahr, dass – wenn sich die Alsa-Lib mal ändert – irgendwas schief läuft, weil das Makro dann vielleicht kein Makro mehr sondern eine richtige Funktion ist, die noch mehr tut.

Naja, fast. Beim GCC könntest du das hier machen, sofern du nicht gleich -Waddress ganz ausschalten willst:

1
2

#pragma GCC diagnostic ignored "-Waddress"
snd_pcm_hw_params_alloca(&hwparams);