Hallo zusammen !
Ich bin relativ neu in der Welt des µC, habe aber schon einige
kleinere Projekte fertiggestellt. Ich programmiere hauptsächlich über
Bascom-AVR.
Ich suche nach einer Möglichkeit oder Hardware, die mehrere
Sound-Dateien (WAV),gesteuert durch einen Atmel (ATtiny oder ATmega),
gleichzeitig/parallel ausgeben kann. Auch sollte die Wiederholung eines
Soundfiles nahezu "Lückenlos" möglich sein. Ich habe derzeit ein
WTV020-M01 Modul im Test, womit ich zwar Soundfiles (WAV & AD4)
abspielen kann , von der micr-SD-card die das Modul hat, aber zwischen
den Files oder bei Wiederholung, dauert es fast 1s. Die Unterbrechung
ist zu lange. Ausserdem kann man keine Sounds gleichzeitig abspielen.
Hier der Link zum WTV020 und dem Steuerprogramm :
https://www.robotikhardware.de/download/Soundmodul_WTV020.pdf
Ich suche nach einer Alternative dafür.
Wäre super , wenn jemand einen Tipp hätte.
Gruß Mina
PS: mir ist schon klar, dass es "etwas" zeit benötigt, eine Sound-Datei
zu laden, aber die Pause erscheint mir sehr lange. Auch wenn ich nur
eine Sound-datei abspiele und dann direkt wiederhole, ist da eine sehr
lange Lücke. Entweder liegt das an der Architektur des WTV020 oder ist
es das Programm? Ich habe zum Testen exakt das Beispiel-PRG benutzt (aus
dem Link-PDF) , bis auf einige Änderungen Am Anfang des PRG (ATmega8
statt 644p und Programmercode weggelassen).
Gruß Mina
Bei SD Karten hat man immer eine Latenz. Weiß das Programm denn vorher
schon was als nächstes gespielt werden soll und könnte Daten schonmal
vor-laden? Wie groß ist die gesamte Datenmenge?
Vielleicht ist das STM32F7 Discovery sinnvoll - es hat einen per SD-bus
angebundenen microSD-Slot (schnell), 8 MByte RAM (viel Puffer für
Sound-Daten), genug Rechenleistung um eine Menge Sounds zu kombinieren
und einen Audio-Codec und Klinke-Buchse um das Signal auf Kopfhörer oder
Lautsprecher auszugeben. Vielleicht ist aber ein oller R-PI
sinnvoller...
Was bedeutet "gleichzeitig"? Gleichzeitig auf mehreren separaten
Audioausgängen (d.h. ein Audiofile pro Ausgang), oder gemischt auf einem
Audioausgang?
Guten Morgen !
Also: die Dateien liegen als WAV oder AD4 Format alle nacheinander auf
der SD
Karte. Diese müssen lt. PDF des WTV020
https://dlnmh9ip6v2uc.cloudfront.net/datasheets/Widgets/WTV020SD.pdf
alle als 0000.WAV, 0001.WAV...usw. (oder .AD4) benannt sein. Sampling
Rate AD4 = 6-36KHz, WAV 6-16KHz. 16 Bit DAC/PWM Audio output. Insgesamt
512 Dateien, die Grösse spielt wohl keine Rolle.
In meinem Fall liegen die Dateien mit einer Abtastrate von 11025 in Mono
vor und sind zwischen 1 KB und ca 110KB gross.
Das ganze ist gedacht als Geräusch Modul für ein RC-Modell. Je nach
Knüppelstellung oder welcher Kanal aktiv ist, soll ein entsprechendes
Geräusch aktiv sein-z.B. Motor-Leerlauf. Dafür müsste ich aber z.b. für
den Leerlauf eine Loop abspielen können ohne Lücke.
Mehrere Dateien gleichzeitig muß nicht unbedingt sein, aber lückenlos
nacheinander , bzw loop ohne (nennenswerte) Lücke.
Das STM32F7 Discovery ist wohl definitiv zu gross.
Was ein R-Pi ist muss ich mal googeln...
Gruß Mina
Mina K. schrieb:> Was ein R-Pi ist muss ich mal googeln...
Ein raspberry pi.
Für Deine Anwendung halte ich das für kompletten Overkill. Das schafft
ein halbwegs geschickt programmierter 8-Bit-AVR, auch dann, wenn er die
Audiodateien von einer SD-Karte lädt. Sinnvoll ist es, diese dann gleich
in einem einheitlichen (alle in der gleichen Samplerate!)
unkomprimierten Format abzuspeichern, damit sie ohne größere
Konvertierung/Interpretation an den DAC ausgegeben werden können.
Mina K. schrieb:> Insgesamt 512 Dateien, die Grösse spielt wohl keine Rolle.
Schade. Hätte man die gesamt Größe gewusst, könnte man überlegen ob die
Nutzung eines Flash IC's sinnvoll wäre; darauf kann man deutlich
einfacher und schneller zugreifen. Vielleicht hätte sogar ein uC mit
großem internem Flash gereicht.
Hallo !
Alle in der gleichen Sample-Rate wäre ja gegeben. Liegen bei mir alle
als AD4 mit 11025 Rate auf der SD. Nur die Verarbeitung ist jetzt halt
ein "Rätsel" für mich. Es gibt solche Fahrgeräuschmodule z.B. für
Panzer. Diese sind dann in einem fahrtregler integriert und spielen auch
Sound-Dateien (die man übertragen kann) ab. Aber so ein
Fahrtregler-Modul ist dann sehr speziell (viele Funktionen die ich nicht
brauche/die nicht passen) und kostet gut 250€. Das ist auch zu drüber.
Ich habe ja eine gute Grundlagen mit den Atmel-AVR's.
SD-Karten zu lesen ist nun auch keine Raketenwissenschaft und hat
--sofern man die restlichen Rahmenbedingungen sinnvoll anpasst-- auch
keinen Overhead, der in sekundenlangen Pausen o.ä. resultiert.
Okay, aber DA fehlt mir die wichtige Info , oder ich mache was falsch
bei der Software (Beispiel-PRG aus dem PDF). Leider sind die Fakten
momentan so.
Generell klappt ja alles - ich kann via Software (im 2-line-serial-mode)
dem Modul sagen "spiel Sound XYZ" , es wird sogar die "busy"-Leitung
berücksichtigt. Aber die Lücken sind das Problem. Die Sound -Qualität
ist sogar relativ gut. Ein Lautsprecher mit 3W@8R kann direkt an das
Modul, eigentlich super...aber die Lücken.
Grüße - Mina
Herbert schrieb:> Beitrag "Kleines Abspielgerät für verschiedene Audiokanaäle> gleichzeitig"
Habe ich mir angesehen. Memsolution gibt es nicht mehr und bei
"Neurocore" kann ich mir zwar irgendwelche "Descriptions" durchlesen ,
aber ich sehe noch nicht einmal Bilder oder ein "Modul" , oder shop !?
Sorry- bin etwas verwirrt, wo ich da die entsprechende Info ziehen
soll...
Grüße Mina
PS : es gibt ja auch diese tolle Projekt :
http://elm-chan.org/works/sd8p/report.html
Aber leider habe ich keine Ahnung von Assembler. Ich muss mich auf
Bascom beschränken :-(
@Mina K. (mina-c)
>In meinem Fall liegen die Dateien mit einer Abtastrate von 11025 in Mono>vor und sind zwischen 1 KB und ca 110KB gross.>Das ganze ist gedacht als Geräusch Modul für ein RC-Modell. Je nach>Knüppelstellung oder welcher Kanal aktiv ist, soll ein entsprechendes>Geräusch aktiv sein-z.B. Motor-Leerlauf. Dafür müsste ich aber z.b. für>den Leerlauf eine Loop abspielen können ohne Lücke.
Das ist einfach.
>Mehrere Dateien gleichzeitig muß nicht unbedingt sein, aber lückenlos>nacheinander , bzw loop ohne (nennenswerte) Lücke.
AHA!
>Das STM32F7 Discovery ist wohl definitiv zu gross.
Das kann ein kleiner ATtiny. Das Projekt wurde ja schon genannt.
>http://elm-chan.org/works/sd8p/report.html>Aber leider habe ich keine Ahnung von Assembler. Ich muss mich auf>Bascom beschränken :-(
Vergiss es. Das geht nur, wenn ein Assembler-Kenner dir eine passende
Lib für BASCOM erstellt.
Hallo !
Okay - also ist hier für mich die Reise zuende. Davon verstehe ich
nichts.
Ich habe aber evtl. gerade noch bei der Suche im Netz etwas gefunden,
was auf dem Projekt von Elm-Chan basiert. ELV hat sich wohl mal diesem
open source project angenommen und den MWP1 + 2 entwickelt.
https://www.elv.de/mini-wave-player-mwp1-bausatz.html
Preislich liegt das völlig im Rahmen, Baugrösse sowieso und die
Ansteuerung über 4-Bit für 15 Sounds (bzw. 4 Taster) sollte dann über
AVR und Bascom super gehen. Schnell, bzw. lückenlos scheint es zu sein.
Betriebsart "0" - endlosplay, solange bis der Eingang wieder auf high
geht...
Klingt echt gut und ist einen Versuch wert.
Aber auch mein WTV020 ist eigentlich bei Tastenbedienung extern an
"prev" oder "next" und "play/pause" recht fix. Nur bei der Bedienung
über die Software (Befehl Shiftout) ist es langsam, bzw habe ich die
Lücken.
Naja.
Danke erstmal - ich versuche es mit dem MWP1 bzw. 2
Gruß Mina
Falk B. schrieb:> Das kann ein kleiner ATtiny. Das Projekt wurde ja schon genannt.
Bei CD-Qualität kann der ca. 5ms puffern in seinen 512 Bytes RAM...
Reicht das bei den üblichen Latenzen von SD-Karten, insbesondere weil
die bei SPI ja immer Speed Class 0 haben (keine garantierte Datenrate)?
Ach ich sehe gerade dass die Qualität geringer ist, wären bei 11025
Samples/Sec dann 20ms Puffer. Geht vielleicht, aber für mehrere Kanäle
wird's knapp, weil ja auch beliebig zwischen FAT und Dateien hin und her
gesprungen werden muss.
@Dr. Sommer (Gast)
>> Das kann ein kleiner ATtiny. Das Projekt wurde ja schon genannt.>Bei CD-Qualität kann der ca. 5ms puffern in seinen 512 Bytes RAM...
Der OP verlangte nach 11kHz, nicht 44,1kHz. Und selbst die sind bei Mono
mit ~ 90kB/s lächerlich wenig für eine SD-Karte, selbst die
allerschlechtesten und billigsten. Und wenn es nur 8 Bit sind erst
recht.
>Reicht das bei den üblichen Latenzen von SD-Karten, insbesondere weil>die bei SPI ja immer Speed Class 0 haben (keine garantierte Datenrate)?
Welche Latenzen denn? Bei Lesen? 5ms sind da ne Ewigkeit.
Falk B. schrieb:> Welche Latenzen denn? Bei Lesen? 5ms sind da ne Ewigkeit.
Okay... Hab bisher nur hauptsächlich beim Schreiben auf die Latenz
geschaut und da geht das manchmal bis 2sec rauf. Na dann sind F7 und
R-PI wirklich Overkill.
@Dr. Sommer (Gast)
>Okay... Hab bisher nur hauptsächlich beim Schreiben auf die Latenz>geschaut und da geht das manchmal bis 2sec rauf.
2 Sekunden? Dann ist aber was oberfaul! Ich weiß nicht was in der
SD-Spezifikation steht, aber 2s sind ja eine Ewigkeit!
Falk B. schrieb:> @Dr. Sommer (Gast)>>>Okay... Hab bisher nur hauptsächlich beim Schreiben auf die Latenz>>geschaut und da geht das manchmal bis 2sec rauf.>> 2 Sekunden? Dann ist aber was oberfaul! Ich weiß nicht was in der> SD-Spezifikation steht, aber 2s sind ja eine Ewigkeit!
Die Spezifikation gibt keine Latenzen an und fordert nur
Durchschnitts-Datenraten. Da die 2sec-Pausen eher selten auftreten
mittelt sich das weg. Man braucht eben sehr große Puffer. Es war aber
auch ne ziemlich billige Karte (SanDisk); bei besseren sieht das schon
ganz anders aus (ca 100ms).
@ Dr. Sommer (Gast)
>Die Spezifikation gibt keine Latenzen an
Wirklich? Als dürfte eine Karte auch 10s Pause einlegen? OMG!
>und fordert nur>Durchschnitts-Datenraten.>Da die 2sec-Pausen eher selten auftreten>mittelt sich das weg.
Das reicht auch nicht.
> Man braucht eben sehr große Puffer.
DAS ist das Problem! Vor allem bei höheren Datenraten bzw. kleineren uCs
mit eher wenig Speicher.
> Es war aber auch ne ziemlich billige Karte (SanDisk)
Ist das eine Ramschmarke?
> bei besseren sieht das schon ganz anders aus (ca 100ms).
Klar, aber man muss ja mit dem schlimmsten rechnen, vor allem wenn es um
den Zwischenpuffer geht. Und da wäre eine VERBINDLICHE Spezifikation
einer maximalen Schreibpause schon sehr hilfreich.
Falk B. schrieb:> Wirklich? Als dürfte eine Karte auch 10s Pause einlegen? OMG!
Glaube schon...
Falk B. schrieb:> DAS ist das Problem! Vor allem bei höheren Datenraten bzw. kleineren uCs> mit eher wenig Speicher.
In Video-Kameras, für die das ja gedacht ist, arbeitet meistens kein
kleiner uC... Da ist genug RAM für sowas.
Falk B. schrieb:> Ist das eine Ramschmarke?
Ja, ziemlich. Die haben die SD-Karten ja auch erfunden...
Falk B. schrieb:> Und da wäre eine VERBINDLICHE Spezifikation> einer maximalen Schreibpause schon sehr hilfreich.
m.W. gibt's aber keine. Die Speed Class ist auch nur sehr schwammig
definiert und greift nur unter bestimmten Bedingungen. Deswegen ja auch
der Vorschlag mit dem Flash-IC.
Guten Tag zusammen !
Gibt es denn noch irgendeine Chance im Code-Beispiel etwas zu verändern,
um der Lücke evtl. bei zu kommen ?
Könnte ich da etwas anders machen, um z.B. die Abspielgeschwindigkeit
der Sounddatei zu ändern? Es geht mir hauptsächlich darum einen
Proportionalen Motor-Sound zu bekommen...
Gruss Mina
foobar schrieb:> Du hast aber schon sichergestellt, dass die Soundfiles selbst nicht> Stille am Anfang oder Ende haben?
Sorry - überlesen :
Ja, habe ich: Mit Audacity bearbeitet.
Gruß Mina
