Name des Programms:
CSCore - C-Sharp-Sound.

Beschreibung:
CSCore ist eine mittlerweile recht umfangreiche Audio-Bibliothek. Sie wurde komplett in C# geschrieben, kann somit aber auch genauso gut in VB.NET verwendet werden.
Die Architektur ist darauf ausgelegt, dass diese möglichst erweiterbar bleibt und somit dem Benutzer keine Einschränkungen bietet.

Für eine aktuelle Liste der unterstützen Features etc. besucht bitte die offizielle Projektseite(n):

github.com/filoe/cscore
CSCORE - cscore.codeplex.com

Beispiele:
Finden sich unter github.com/filoe/cscore/tree/master/Samples

---

Demovideos:
[b]


Der Download befindet sich im Anhang(zusammen mit ein paar Beispielen). Ich gehe nicht davon aus, dass jemand diese Bibliothek ernsthaft verwenden wird, jedoch wäre es trotzdem schön wenn jemand zumindest ein paar Tests damit machen könnte und bei Bugs Fehlern oder vll. sogar positiven Erfahrungen ein entsprechendes Feedback gibt(dabei aber bitte korrekt und nicht beleidigend :)). Wie gesagt die Lib ist noch nicht fertig und somit wird den meisten der Funktionsumfang nicht ausreichen. Außerdem hoffe ich, dass sich möglicherweise noch jemand für das Thema interessiert und vll. sogar mitmachen möchte . Und wenn nicht... dann war dies einfach nur eine kleine Demo was man alles tolles mit Audio machen kann .

Screenshot:
Beispiel(Source im Anhang):
s1.directupload.net/images/130413/kml7vcoo.png




Verwendete Programmiersprache und IDE:
Sprache: C# .NET 3.5 Client Profile
IDE: Visual Studio 2012 Ultimate

Systemanforderungen:
.NET 3.5 Client Profile
Minimum: Windows 2000 Prof/Windows Server 2000
Empfohlen: Windows Vista+
Anforderungen richten sich teils auch nach den verwendeten Features

Download:

1.4.1 CSCore + Beispiele
1.4.2 CSCore + Beispiele
1.4.3 CSCore + Beispiele
Download auf Codeplex: cscore.codeplex.com/ oder über NuGet :



Lizenz/Weitergabe:
MS-PL. Erwähnung ist jedoch sehr sehr wünschenswert und ich denke auch nicht wirklich zu viel verlangt.


Anhänge nicht downloaden! Download steht oben unter "Download"

Ja theoretisch kannst du es als Bass.dll Alternative nutzen. Jedoch hast du halt leider noch nicht den Funktionsumfang von Bass.dll weil diese nunmal auch wesentlich mehr Formate unterstützt usw. Würde aber gern noch mehr Formate implementieren. Ist halt eine Zeitfrage. Aber Grundsätzlich steht das Gerüst recht solide und auch noch etwas mehr

Wie gesagt ich werde versuchen neue Features hineinzubringen. Jedoch muss ich nebenbei auch vermehrt noch testen, da es recht viel Code ist können auch Bugs auftreten. Wenn natürlich jemand wie z.B. Krissel das auch einmal ausprobiert und einen Bug findet, bin ich dankbar wenn ihr diesen beschreiben könnt und ihn so schnell wie möglich beheben kann.

Gonger96 schrieb:

Mir ist grad etwas Seltsames aufgefallen. Wenn ich während des Abspielens meine Tastatur ausm USB-Port nehme, dann hackt das Programm. Sowohl die Wiedergabe als auch die Grafik hackt.

Liegt an DirectSound. Bin an WASPI dran wenn ich mal Zeit hätte. Braucht leider verdammt viel mit Resampler, Comimporten,... usw.
Außerdem wird nicht nur WAVE unterstützt. Es basiert darauf. Unterstützt wird auch MP3 und FLAC. Der Grund weshalb es hackt ist, dass du bei Visualisierungen eine sehr geringe Latenz wählen muss. Darauf ist auch der DirectSound-Wrapper optimiert worden. Du kommst damit teilweise sogar fast auf 50ms was dann doch extrem schnell ist. Das heißt 1000/50 mal Daten decodieren, fft berechnen, darstellen und Daten den Treibern geben + Format umwandeln usw. Wenn da dein System einen kleinen Lag hat und dieser nur einige wenige ms dauert hört man das. In der Demo läuft es auf ca. 100ms Latenz. Aber wie gesagt, da kann das Programm an sich nichts für sondern halt das System. Einzige Chance die eine Besserung bringen würde sind neuere Schnittstellen wie z.B. WASAPI welche auf Kernelebene läuft.
Außerdem kann das Problem auf Win8 mit dem USB nicht reproduzieren, kann aber durchaus sein. Wie gesagt. Auf höherer Latenz laufen lassen aber dann ist die Darstellung nicht mehr flüssig, da nur alle 300ms gepuffert wird(z.b.). Die Lib ist jedoch für solche Optimierungen welche ein besseres Pufferingsystem nutzen sehr offen und kann von jedem innerhalb kurzer Zeit hinzugefügt werden.

Kurze Auflistung was alles dazu gekommen ist:

• Microaufnahme(WaveIn - FunctionCallback, WindowCallback und EventCallback)
• WASAPI(Shared- und Exclusive-Mode + EventCallback oder normales "Loopcallback" <- kein Loopback)
• Resampler(Samplerate, BitsPerSample, Channels verändern; inklusive Support für beliebige ChannelMatrix)
• Allgemeiner Wrapper für DMO, MediaFoundation und CoreAudioAPI
• ID3v1 und ID3v2.[2,3,4] Implementation
• Postcompiler überarbeitet
• Neue Implementation von WPF Visualisierungen
• Diverse Bugfixes
• Veraltete Klasse, Methoden,... entfernt
• Teilweise Namespaces neu organisiert
• Paar Spielereien wie z.B. Echo-Effekt
• etc.

Download im Startpost Version 1.4 inklusive 2 Beispielen.

Hmmm. Der Flac Decoder müsste eigentlich nach wie vor laufen. Kannst du mir vll. mal die Flac-Datei geben? Habe viele verschiedene Flac-Dateien mit verschiedenen Formaten und Encodern getestet. Hatte nie Probleme.

Btw.: Ganz vergessen. Habe "nebenbei" auch noch ID3v1 und ID3v2.* neu implementiert. Bei ID3v2 werden derzeit 56 von 62 Framearten unterstützt. Die restlichen kommen im nächsten Release.
Ich habe auch grad noch die Lautstärke für WASAPI implementiert. Und wie gesagt wäre dankbar wenn du mir mal die Flac-Datei geben könntest.

WASAPI und Flac sollte sich vertragen, da a) Wenn das Format nicht unterstützt wird sollte ne Exception fliegen und b) Flac zu rohem PCM decodiert wird.

EDIT: Irgendwo im Flac-Decoder muss nen kleiner Fehler sein. Wasapi arbeitet mit einer extrem kleinen Latenz. Das verträgt er nicht. Ich werde mal suchen gehen(mal wieder...). :thumbsup:
EDIT2: Bug behoben. Danke @Manawyrm. Der Fehler war so simpel, dass ich mich wundere wieso ich den nicht schon früher gesehen habe. Intern puffert der Flacdecoder decodierte Frames welche derzeitig noch nicht benötigt werden -> ansonsten würden ja Daten verloren gehen. Jetzt ist es so, dass beim nächsten mal Lesen die überschüssigen Daten vom letzen mal Lesen wieder übernommen werden. Bei höheren Latenzen(100-300ms) wird dieser Puffer immer zu 100% geleert(oder zumindest in 99,9% der Fälle). Bei sehr geringen Latenzen sind die angeforderten Daten kleiner als ein Frame im Flac Stream und somit wird aus dem Puffer 2 mal gelesen. Jetzt habe ich vergessen den Offset für den Puffer zu aktualisieren und somit wurde immer der ganze Puffer erneut gelesen -> nicht gut