Clip zu SourceDataLine

[Chloroplast]

Ich habe die frage schon bei Multimedia gestellt, bekam aber keine antwort

Ich bin gerade dabei eine kleine Application zu schreiben, mit der man töne (die ich alle als .wav datei in einem ordner habe) durch tastendruck abspielen kann.

Diese lade ich dafür in ein clip array:

for(int cc = 0; cc<30; cc++){
        try{
 
        URL url = this.getClass().getClassLoader().getResource("sounds/"+what+"/"+what+""+(cc+1)+".wav");
        AudioInputStream audioIn = AudioSystem.getAudioInputStream(url);
        clip[cc] = AudioSystem.getClip();
        clip[cc].open(audioIn);
        }
        catch(Exception e){
            System.out.println("fehler beim einlesen der datei: "+"sounds/"+what+"/"+what+""+(cc+1)+".wav");}
        }

wobei der String "what" die art des waves ist (zb. drums, wenn man schlagzeugtöäne ausgeben will)

danach frage ich die tasten in der keyPressed Methode ab und gebe die töne mit
Java Code: Quelltext in neuem Fenster öffnen

clip[die taste].loop(1);

nun möchte ich bei bedarf einen hall auf die gesamte audioausgabe legen. dafür habe ich im bei google das hier gefunden:

SourceDataLine line;
FloatControl control = (FloatControl) line.getControl(FloatControl.Type.REVERB_RETURN);
control.setValue(..);

Allerdings habe ich ja keine SourceDataLine, und ich muss gestehen das ich damit auch recht wenig anfangen kann. hoffe auf hilfe

 

[Marco13]

Ja, gesehen hatte ich den Thread, aber ... dachte jemand, der sich da mehr auskennt, würde antworten... Ein Codesnippet habe ich dafür auch gerade nicht, aber ... man kann keinen Clip in diesem Sinn in eine SourceDataLine umwandeln. Man kann aber vom AudioSystem einen Mixer holen, und von dem dann mit getLine eine (SourceData)Line. Mehr steht hier Playing Back Audio (The Java™ Tutorials > Sound) , sag' bescheid wenn's nicht klappt (aber... du musst damit rechnen oder sogar davoan ausgehen, dass man NICHT ohne weiteres einfach so mit 3 Zeilen einen Hall über jeden Sound legen kann... du kannst es versuchen, aber ggf. bietet die Line diesen Control einfach nicht an... :bahnhof: )

 

[Spacerat]

Hast du evtl. ma ausprobiert, ob das mit den Controls nicht auch bei Clips geht? Denke nicht, sonst wüsstest du, dass es klappt (unter Umständen jedenfalls).

Clip clip;
FloatControl reverb = (FloatControl) clip.getControl(FloatControl.Type.REVERB_RETURN);
reverb.setValue(value);

Aber bevor man so etwas macht, sollte man erst mal freundlich anfragen, ob eine Control auch vom System unterstützt wird (nicht bei mir, beim Clip natürlich ). Also ganz allgemein etwa so:

Line line = (Line) myClip; //mySDL, myTDL...
if(line.isControlSupported(FloatControl.Type.REVERB_RETURN)) {
  FloatControl reverb = (FloatControl) line.getControl(FloatControl.Type.REVERB_RETURN);
  reverb.setValue(value);
}

[EDIT]BTW.: Den anderen Thread hab' ich bis eben auch völlig übersehen... Naja, war ja nicht wichtig, hier steht ja das selbe. XD[/EDIT]

 

[Chloroplast]

danke erstmal für die antworten... ich probier das morgen mal aus weil ich heute echt nichmehr kann... ich seh schon zeichen wenn ich die augen zumache gute nacht, bis morgen

 

[Chloroplast]

also... @Spacerat, Reverb_return wird vom Clip nicht unterstützt...

ich habe mir das mit dem Mixer angesehen, steig aber nicht recht durch... Soweit ich das verstanden habe, müsste ich die Line vom Proggram aus dem Mixer holen und dann da die FloatControl für REVERB_RETURN holen. ich kann da aber nicht draus erkennen wie.

 

[Spacerat]

Das ist schlecht... dann kann man fast davon ausgehen, dass die SourceDataLine das auch nicht unterstützt. Lustigerweise richtet sich hier das DirectAudioDevice lt. Doku nach der verwendeten Hardware im System (nbb: Das hätte es meiner Meinung nach lieber mal bei der Anzahl der Kanäle tun sollen. ).
Soweit ich das überblicke unterstützt Suns DirectAudioDevice nach wie vor nur 4 Controls (Pan, Mute, Gain und Volume), zumindest bekommt das ControlArray der gemeinsam verwendeten AbstractLine nur diese Elemente und den QTs zu Folge wird das Array auch an keiner anderen Stelle erweitert, oder ich hab' sie noch nicht gefunden. ???:L
Das Java-Sound-API ist im übrigen nicht dafür Verantwortlich, was Sun (oder jetzt Oracle) davon in seinem DirectAudioDevice verwendet. Es können auch andere Devices per SPI eingebunden werden, aber finde da mal welche. Ich hab' noch keines gefunden und deswegen 'ne Reihe Devices im Entwicklungsstadium, die entweder LWJGL oder JOAL benötigen. Daran, dass das Originale Sun-Device noch mitgeladen und Ressourcen belegt ändert das aber leider nichts.
[EDIT]Naja... ein Gutes hat das Ganze... man lernt die API kennen. XD[/EDIT]

 

[Chloroplast]

dh. es ist so gut wie unmöglich, einen "simplen" hall auf den audioausgang zu legen?

 

[Marco13]

Eine einfache Möglichkeit gibt es: Man kann den PC in einer großen Höhle aufstellen, laut aufdrehen... :joke:

Ne, im Ernst: So einfach ist das nicht, per Software oder über eine einfache API wie
magicallyAddEcho(soundData);
Wenn sowas "zufällig" unterstützt und über dieses REVERB_RETURN nach draußen geleitet wird, ist das schön, aber wie gesagt: Das braucht man nicht zu erwarten. Es gibt bei einigen Soundkarten innerhalb des Treibers die Möglichkeit, Echos hinzuzufügen, aber das hilft dir wohl nichts. OB man da jetzt wirklich per Hand mit einer FFT drangehen muss, weiß ich nicht, vielleicht hat jemand anderes noch eine ... "praktikable" Idee dazu....

 

[Spacerat]

Tja... muss man wohl selbst implementieren, wer hätt's gedacht... Wer hätte gedacht, dass das Java-Sound-API nach so vielen Jahren immer noch nicht ausgereift ist.
Diese Seite (An example of playing a sound with an echo filter : SoundDevelopment ClassJava) hab' ich mir mal gebookmarked.

 

[Marco13]

Ha, die Seite hab' ich immer verlinkt wenn jemand nach Java3D-KSKBs gefragt hat - anscheinend gibt's da auch praktische Sound-KSKBs (und andere, BTW). Aber... das "übliche" Problem bei allem, was mit Sound zu tun hat

/* ... Samples should be in 16-bit, signed,
 * little-endian format.
 */

... Aber vielleicht löst es das Problem ja trotzdem...

 

[Spacerat]

Diese Aussage ist nur bedingt richtig, der Endian ist egal. Erinnerst du dich, an meine ensurePCM-Methode? Die war auch noch Verbesseungswürdig. Das einzige, was das DirectSoundDevice aus der HW liest sind die unterstützten AudioFormate und die sind (das kann ich nur auf meinen Rechnern testen) durchweg PCM-Formate. Das DirectAudioDevice macht aus 4 HW-Formaten (btw.: bei meiner HW sind's immer die selben; U_8_1, U_8_2, S_16_1_L und S_16_2_L) 8 SW-Formate (+ S_8_1, S_8_2, S_16_1_B und S_16_2_B). Diese 8 Formate kann das Device auch direkt verarbeiten, alles andere muss gewandelt werden.
An dieser Stelle ist die gesamte API relativ dämlich implementiert:
1. Man kann anfragen ob eine Konvertierung unterstützt wird, kommt aber nur sehr schwer an die unterstützten Audioformate.
2. Hat man sich nun durch die Anfragen durchiteriert und ein passendes Format gefunden, darf man den Stream auch noch selber konvertieren.
Wäre es an dieser Stelle nicht besser gewesen, dass einem die API entweder zu einem nicht unterstütztem Format eines liefert in das es konvertiert werden kann oder die Konvertierung gleich selbst übernimmt? Das kann man nämlich recht einfach mit einer Map automatisieren. "ensurePCM" war da nur der Anfang.

 

[Marco13]

Hmja, ich bin da noch nicht so drin, aber soweit ich weiß ist das, was dort als "DirectSoundDevice" ausgegeben wird auch noch sehr "gutmütig" - also das spielt alles mögliche ab, keine Ahnung, da wird wohl irgendwie über die Treiber in Software was emuliert oder so... :bahnhof: Es gibt aber auch Fälle, wo das genaue Format ziemlich wichtig ist (spätestens, wenn man selbst manuell dort irgendwelche Veränderungen vornehmen will ). Die "Automatische Konvertierung", die du angesprochen hast, wird ja ""indirekt"" gemacht: Ich hab mir mal Teile von AudioSystem & Co angesehen. Wenn man dem einfach einen Clip hinwirft, nudelt der alle möglichen Mixers, Lines, Converters und was weiß ich nicht alles durch, bis er auf irgendwas trifft, was mit dem übergebenen "Ding" irgendwas anfangen kann. Schön abstrahiert, aber ... sieht halt hakelig aus, und reicht natürlich auch für manche Sachen einfach nicht...

 

[Spacerat]

Hmja, ich bin da noch nicht so drin, aber soweit ich weiß ist das, was dort als "DirectSoundDevice" ausgegeben wird auch noch sehr "gutmütig" - also das spielt alles mögliche ab, keine Ahnung, da wird wohl irgendwie über die Treiber in Software was emuliert oder so... :bahnhof: Es gibt aber auch Fälle, wo das genaue Format ziemlich wichtig ist (spätestens, wenn man selbst manuell dort irgendwelche Veränderungen vornehmen will ). Die "Automatische Konvertierung", die du angesprochen hast, wird ja ""indirekt"" gemacht: Ich hab mir mal Teile von AudioSystem & Co angesehen. Wenn man dem einfach einen Clip hinwirft, nudelt der alle möglichen Mixers, Lines, Converters und was weiß ich nicht alles durch, bis er auf irgendwas trifft, was mit dem übergebenen "Ding" irgendwas anfangen kann. Schön abstrahiert, aber ... sieht halt hakelig aus, und reicht natürlich auch für manche Sachen einfach nicht...

Hast du schon mal versucht ein ALAW oder ULAW abzuspielen? Es wär ja schön, wenn er selbst konvertiert, aber nee, er schmeisst 'ne Exception, nach dem er mit mit dem "genudel" fertig ist. Man muss sich vorher leider selbst um die Konvertierung kümmern und die API macht's einem nicht gerade leicht und das genudel, was die API da macht, muss vorher selbst vollzogen werden. Der Umstand ist dämlich aber nicht zu ändern (ausser von den Entwicklern vllt.). Der Witz daran ist ja, dass dieses doppelt-"genudel" überflüssig ist. Leider ruft die API die entsprechende Konvertierungs-Methode (weder lt. QT noch native)

AudioSystem.getAudioInputStream(AudioFormat targetFormat, AudioInputStream source);

nicht selbsständig auf, obwohl es nach dem "genudel" über die div. Formate doch eigentlich ein leichtes sein müsste.