Hallo liebes Forum, Ich möchte einige Samples (Drums, Snares, Hihats, e.t.c.) per (TTL-Pegel) Trigger in möglichst sehr guter Qualität abspielen lassen. Ein Neustart des Samples sollte durch erneutes Triggering ohne Verzögerung stattfinden. Ein einzelnes Sample hätte maximal 2 Sekunden Länge. Hat jemand eine Idee? Ich stehe gerade auf dem Schlauch. Gruß, Freed
Ach ja, da die Trigger noch nicht 100%ig geplant sind würde es mich auch nicht stören pro Trigger einen µC, IC, e.t.c. zu verwenden.
Vor ewigen Zeiten hatte da die Ct ein Projekt. Die Samples in Eproms abgelegt, die Adressleitungen wurden einfach von einem TTL-Zähler hochgezählt und die Datenleitungen gingen an einen D/A Wandler.
Das sollte ein guter bzw. "sehr guter" Drumcomputer für elektronische Schlagzeuge schaffen. Wenn du was einfaches findest, sag bescheid. Ich suche sowas auch. ;-)
Also... Erstmal Danke, für den Vorschlag, aber ich bevorzuge eine etwas kleinere Lösung. Ließe sich das ganze z.B. über einen ATTiny85 mit 44,1kHz in 16bit Mono lösen? Wo finde ich Grundlagen um das zu berechnen? Ich habe bislang nur rudimentäre Erfahrungen in AVRASM mit nem Mega32, denke aber mal das ich das hinbekomme falls die HW das zulässt.
Dussel schrieb: > Das sollte ein guter bzw. "sehr guter" Drumcomputer für elektronische > Schlagzeuge schaffen. > Wenn du was einfaches findest, sag bescheid. Ich suche sowas auch. ;-) Ich durfte bei einem befreundeten Musiker ein Roland SPD-SX ausprobieren. Daher die Idee, da ich mir dass einfach nicht leisten kann.
Du kannst das Zeug wahrscheinlich nicht komprimiert speichern, weil der Controller das nicht dekomprimieren kann. Bei zwei Sekunden wären das dann unter den Anforderungen 44100 Samples pro Sekunde*2 Byte pro Sample*2 Sekunden=176kB. Wo soll das gespeichert werden?
Es gibt kleine Platinen, die wie ein Klingelton mp3s abspielen können. Die lassen sich sicher irgendwie triggern.
Der dsPIC33FJ128GP802 hat Stereo Audio DACs. http://www.microchip.com/wwwproducts/Devices.aspx?product=dsPIC33FJ128MC802 Wie Audio funktioniert, siehst Du hier: http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en542825.pdf Dadran dann ein größeres SPI Flash wie das hier (8MB) http://www.microchip.com/wwwproducts/Devices.aspx?product=SST26VF064B und Du kannst einiges an Samples abspielen. fchk
Dussel schrieb: > Bei zwei Sekunden wären das > dann unter den Anforderungen 44100 Samples pro Sekunde*2 Byte pro > Sample*2 Sekunden=176kB. Mega2560??? Nur mal so als Idee in den Raum gestellt. Wär zwar teuer und blöd zu löten für jeden Trigger, aber erstmal ne Idee. Gibts da nicht nen geeigneten Sound-IC von den Glückwunschkartendingern abgesehen? Muss ich mich echt in die ARM-Technologie einarbeiten?
Audio Hans schrieb: > Es gibt kleine Platinen, die wie ein Klingelton mp3s abspielen können. > Die lassen sich sicher irgendwie triggern. Weisst du wo es die in den Qualitätsanforderungen gibt?
Freed schrieb: > mit 44,1kHz in 16bit Mono lösen? Wo finde ich > Grundlagen um das zu berechnen? Um den benötigten Speicherplatz zu berechnen, musst du einfach nur die Zahl der Samples pro Sekunde (44100) mit der Speichertiefe zu multiplizieren, du siehst, das du für ein unkomprimiertes Sample mit einer Sekunde Dauer 88200 Bytes Speicher brauchst. Das Problem ist also weniger die Verarbeitungsgeschwindigkeit (das schafft heute jeder MC) als der zu verwaltende Speicherplatz. Ein Tiny 85 hätte also mit seinem gesamten internen Speicher Platz für nicht mal 1/10 Sekunde. elm-chan umgeht das, indem er an seinen Tiny Abspieler eine SD Karte als Samplespeicher anschliesst: http://elm-chan.org/works/sd8p/report.html Ein Tiny ist aber schon wegen seiner geringen Pinzahl nicht ausreichend, um z.B. einen guten 16-bit Audio DAC anzusteuern, es sei denn, du traust dir zu, ein I2S Interface mit Bitbanging zu bauen. Mehrere Samples gleichzeitig zu spielen, ist auch eine Herausforderung.
Frank K. schrieb: > Der dsPIC33FJ128GP802 hat Stereo Audio DACs. > http://www.microchip.com/wwwproducts/Devices.aspx?product=dsPIC33FJ128MC802 > > Wie Audio funktioniert, siehst Du hier: > http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en542825.pdf > > Dadran dann ein größeres SPI Flash wie das hier (8MB) > http://www.microchip.com/wwwproducts/Devices.aspx?product=SST26VF064B > und Du kannst einiges an Samples abspielen. > > fchk Nett gemeint, Frank, aber sag mal, gibt es da was im AVR-Bereich? Da hab ich zumindest mal ein wenig was gemacht und wörde, falls erforderlich, gerne dabei bleiben.
Freed schrieb: > einige Samples (Drums, Snares, Hihats, e.t.c.) Mein alter Drumulator von E-Mu Systems benutzt übrigens 8-bit ROMs für die Samples und dekomprimiert sie mit einem µLaw Algorithmus. Das klingt recht gut, zumindest recht kultig 80er Jahre-mässig.
Matthias Sch. schrieb: > Um den benötigten Speicherplatz zu berechnen, musst du einfach nur die > Zahl der Samples pro Sekunde (44100) mit der Speichertiefe zu > multiplizieren, du siehst, das du für ein unkomprimiertes Sample mit > einer Sekunde Dauer 88200 Bytes Speicher brauchst. > Das Problem ist also weniger die Verarbeitungsgeschwindigkeit (das > schafft heute jeder MC) als der zu verwaltende Speicherplatz. > Ein Tiny 85 hätte also mit seinem gesamten internen Speicher Platz für > nicht mal 1/10 Sekunde. Das hat mir schonmal sehr geholfen. Danke. Matthias Sch. schrieb: > elm-chan umgeht das, indem er an seinen Tiny Abspieler eine SD Karte als > Samplespeicher anschliesst: Nette Idee. Ich habe hier noch ein paar 32MB Karten rumfliegen, die ich für die ersten Versuche killen kann. > Ein Tiny ist aber schon wegen seiner geringen Pinzahl nicht ausreichend, > um z.B. einen guten 16-bit Audio DAC anzusteuern, es sei denn, du traust > dir zu, ein I2S Interface mit Bitbanging zu bauen. Ich hab mich noch nicht 100% in das Datenblatt des ATMEGA32 eingelesen. Also ist das nur ein eSache von Learn, Try and Error ;-) Der erste Step wird glaube ich nach längerem Überlegen das mit nem Tiny2313 zu versuchen. Der hätte auch gleich UART für ne MIDI-Ausgabe. Nebenbei tendiere ich aber auch dazu den Trigger mit nem MEGA8 direkt auszulesen und auszugeben. Durch die 6 ADCs hätte ich alls Pins der Welt. > Mehrere Samples gleichzeitig zu spielen, ist auch eine Herausforderung. Evtl. Nicht notwendig. s.o. Danke euch allen für die Denkanstöße und Formeln. Schönes WE.
Bei Reichelt gibt es SPI-EEPROM bis mindestens 1024kB. Je nach gewünschter Anzahl der Samples würde ich davon 1-n nehmen. Jeder davon kann fast sechs Sekunden Sample speichern oder drei mit zwei Sekunden. Alternativ, wie oben genannt, die SD-Karte.
Dussel schrieb: > Bei Reichelt gibt es SPI-EEPROM bis mindestens 1024kB. Je nach > gewünschter Anzahl der Samples würde ich davon 1-n nehmen. Jeder davon > kann fast sechs Sekunden Sample speichern oder drei mit zwei Sekunden. > Alternativ, wie oben genannt, die SD-Karte. Ich habe zwei 24LC512 hier liegen mit denen ich das mal ausprobieren werde. Die waren zwar für ein anderes Projekt gedacht, aber das kann warten...
Freed schrieb: > Frank K. schrieb: >> Der dsPIC33FJ128GP802 hat Stereo Audio DACs. >> http://www.microchip.com/wwwproducts/Devices.aspx?product=dsPIC33FJ128MC802 >> >> Wie Audio funktioniert, siehst Du hier: >> > http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en542825.pdf >> >> Dadran dann ein größeres SPI Flash wie das hier (8MB) >> http://www.microchip.com/wwwproducts/Devices.aspx?product=SST26VF064B >> und Du kannst einiges an Samples abspielen. >> >> fchk > > Nett gemeint, Frank, aber sag mal, gibt es da was im AVR-Bereich? Da hab > ich zumindest mal ein wenig was gemacht und wörde, falls erforderlich, > gerne dabei bleiben. Leider nichts äquivalentes. Ich bin deswegen weg von AVR. Zu wenig Rumms pro Euro. Eine Alternative zum eingebauten Stereo-DAC wären externe I2S-DACs, aber I2S kann kein AVR. Für dsPIC (die dsPIC33EP gehen bis 70 MHz!) und PIC32 kein Problem - die SPI-Einheiten können das, wahlweise auch mit DMA-Unterstützung. Nennt sich dann Framed SPI. Ein schöner DAC aus der oberen Etage wäre der hier zB: http://www.cirrus.com/en/products/cs4398.html Oder etwas günstiger und kleiner: http://www.cirrus.com/en/pubs/proDatasheet/CS4334-5-8-9_F6.pdf Ansteuern kannst Du das dann entweder hiermit: http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX250F128B (32 Bit, MIPS Kern, 50 MHz, 128k Flash, 32k RAM) oder sowas http://www.microchip.com/wwwproducts/Devices.aspx?product=dsPIC33EP256GP502 (16 Bit mit DSP Erweiterungen, 70 MHz, 256k Flash, 32k RAM) Die beiden Prozessoren gibts übrigens auch in DIL. Sind nur 28 Pinner, also leicht zu verarbeiten.
Freed schrieb: > Ich habe zwei 24LC512 hier liegen mit denen ich das mal ausprobieren > werde. Das ist auf jeden Fall einen Versuch wert. SD-Karten haben nämlich das Problem des unvorhersehbaren Timings, es kann schon mal ein paar ms dauern, ehe eine SD-Karte die angeforderten Daten rausrückt - das hängt mit der Speicherverwaltung des internen Controllers auf dem Flashchip zusammen. Man muss also lesen und zwischenspeichern, um eine konstante Ausgaberate zubekommen. Echte EEPROM vom Typ I2C oder SPI haben dieses Problem nicht und liefern ihre Daten sofort. Du musst dir nur überlegen, wie du deine Samples IN den EEPROM bekommst... Bei I2C Zugriff ist das nächste Problem allerdings, das du mit den 'Standard' 100kHz Takten nicht auf die gewünschte Samplerate kommst. Selbst mit highspeed I2C (400kHz) ist die gewünschte Datenrate nicht ereichbar, denn du willst ja 44100 mal 16 bit = 705600 Bits/s. Ein AVR sollte also ein externes Speicherinterface haben (a là Mega2560 oder Mega8515/8535), denn dann kann er parallel auf den Speicher zugreifen, oder eben schnelle SPI EEPROMs.
:
Bearbeitet durch User
ATXmega : 2 DAC (12 bit) , 4 DMA , Eventystem. AVR, billig, klein und easy zu programmieren. Mit einer vernünftigen SDCard (alternativ aber teuer FRam) sind 44Khz Stereo locker zu machen und die 12 bit reichen sicher auch aus. Stefan
STM32F4 Discovery für 15 € kaufen, das hat Mikrocontroller mit 1MB Flash, Audio DAC, Klinke Buchse, Programmieradapter integriert. Bei Bedarf noch per Lochraster einen SD Karten Adapter basteln oder fertigen kaufen. Dank der 192KB SRAM ist es kein Problem genug Daten zu puffern um eine kontinuierliche Datenrate zu erreichen (weit höher als benötigt). Genug Pins für Trigger hat es auch, und Rechenleistung genug für richtiges DSP, damit kannst du auch problemlos mehrere Samples gleichzeitig zu spielen. Das dürfte die Hardware technisch am wenigsten aufwändige, leistungsfähigste und billigste Lösung sein.
Freed schrieb: > aber ich bevorzuge eine etwas kleinere Lösung. Ließe sich das ganze z.B. > über einen ATTiny85 mit 44,1kHz in 16bit Mono lösen? Wo finde ich > Grundlagen um das zu berechnen? Hmm. Grundschule? 44100bit/s * 2s --------------- = 11025Byte 8bit/Byte Der Tiny85 hat 8192Byte Flash. 11025>8192 Schon is' erstmal Ende Gelände. Zumal das Programm ja auch noch in den Flash gepackt werden muß... Außerdem: Wie soll das Signal aus einem Tiny85 überhaupt rauskommen? Der hat maximal 6 Portpins, über die man etwas ausgeben könnte, da kriegt man bei paralleler Ausgabe nunmal keine 16 Bit drüber, weil (wieder Grundschule: 6 << 16). Aber es käme ja immerhin noch serielle Ausgabe, z.B. an einen DA-Wandler in Frage (wäre sowieso weitaus besser). Das geht mit 2..3 Pins ab, wäre also möglich. Wenn du auch mit 1,5s Samplelänge auskommen kannst, wird's grundsätzlich realistisch und man kann anfangen, darüber nachzudenken, ob die Rechenleistung genügt. Pro Byte: Polling eines Portpins kostet 2 Takte, Schleife kostet 2 Takte. Lesen eines Byte aus dem Flash kostet 3 Takte, Einfüllen in's USI kostet einen Takt, Takterzeugung für den seriellen Client kostet einen Takt. Größenordnungsmäßig (ohne die natürlich noch nötigen Feinheiten) wären also irgendwas bei 0,9MByte/s Durchsatz @8MHz möglich. Das ist so unendlich weit von dem nötigen Durchsatz von nur 5,5kByte/s entfernt, daß man wohl getrost behaupten kann: Das ginge ganz sicher auch in C... Bloß wird dann deutlich weniger Flash für die Samples über bleiben, als wenn man es in Asm schreibt...
c-hater schrieb: > Hmm. Grundschule? > > 44100bit/s * 2s > --------------- = 11025Byte > 8bit/Byte > > Der Tiny85 hat 8192Byte Flash. Das ist natürlich Unsinn. Es handelt sich nicht um Bit/s, sondern um Samples/Sekunde und jedes Sample hat 16 Bit. Die Rechnung hatte ich schon oben aufgemacht und der TE hat drauf geantwortet. Man benötigt für ein Sample mit 1 Sekunde Dauer und der gewünschten Qualität (44,1kHz, 16 bit) also 88200 Bytes Speicher. Beitrag "Re: Audio in möglichst guter Qualität samplen" c-hater schrieb: > Bloß wird dann deutlich weniger Flash für die Samples über bleiben, als > wenn man es in Asm schreibt... Blablabla. Im gleichen Beitrag weise ich auch auf Elm-Chans Projekt hin, der als Speicher für die Samples eine SD Karte nimmt und das ganze mit dem Tiny ausliest und ausgibt. Lese mal alle Beiträge, bevor du hier was absonderst, wir waren uns schon länger drüber klar, wie so etwas aussehen muss - und Assembler hilft da auch nicht. Dr. Sommer schrieb: > STM32F4 Discovery für 15 € kaufen Das ist vermutlich die günstigste Lösung, leider hat der F4 Disco nur recht wenig RAM. Aber es ist nicht so schwierig, einen USB Stick als Samplespeicher anzusprechen - es ist lediglich eine Frage der neuen Hardware, mit der man Erfahrung sammeln muss.
Ein weiterer möglicher Controller wäre einer aus der STM32F103-Familie mit 1MB internem RAM, so dass etwa 11 Samples intern speicherbar wären. Dafür muss dann allerdings ein externer DAC angeschlossen werden. Da der TE auch eine "möglichst gute Qualität" fordert, kommt ohnehin nur ein spezieller Audio-DAC der Spitzenklasse wie z.B. der von Frank K. erwähnte CS4398 infrage.
Auch ein F429Discovery hätte alles, was der Siedler braucht inkl. 8MB RAM und man könnte sogar Samples per Touchscreen abspielen - aber die Pinbelegung ist ein Abenteuer. Allerdings ist das SAI1 auf die Ports PE2-PE6 zu mappen und diese liegen sogar auf der Anschlussleiste. Wenn man hier also einen I2S Audio DAC anpappt, wäre man auf der Hardwareseite fertig und kann sich dabei noch Bildchen auf dem TFT angucken oder eben Triggerbuttons anzeigen. USB-OTG dann für den USB Stick, oder als CDC für Midi.
:
Bearbeitet durch User
Ich werde für die ersten Test nen Mega32 nehmen. Der liegt hier rum und ich hab ca. 31kByte frei. Im nächsten Schritt werde ich da nen EEPROM dranknallen. Wenn das alles (bis dahin PWM) läuft, werde ich nen DAC dranhängen. Anschließend werde ich das auf nen Mega8 oder ähnlich portieren und erweitern. So will ich z.B. in Zukunft noch Drum-Pads anschließen und auch Midi ausgeben. Die Samples bekomme ich dann in der Finalen Version ebenfalls über Midi rein. Programmiert wird alles in ASM. Irgendwelche Verbesserungsvorschläge bzgl. der Vorgehensweise? Hänge grad am ersten Code für uc-internen Flash und PWM.
Freed schrieb: > Ich werde für die ersten Test nen Mega32 nehmen. Der liegt hier rum und > ich hab ca. 31kByte frei. > Im nächsten Schritt werde ich da nen EEPROM dranknallen. > Wenn das alles (bis dahin PWM) läuft, werde ich nen DAC dranhängen. Ich dachte, Du wolltest eine möglichst gute Qualität haben. So wird das maximal 8 Bit "Qualität" werden. Einem ernsthaften Vergleich wird das niemals standhalten. So hart das klingt, aber für ein wirklich überzeugendes Ergebnis ist das einfach die falsche Architektur. Ich habe Dir geeignete Wege aufgezeigt, andere Poster in diesem Thread ebenfalls. Den Weg gehen musst Du selber. Dass das mit Lernen verbunden ist, sollte dem Ganzen nicht entgegen stehen. fchk
Es sieht für mich gerade so aus, dass man den Ton in 16bit Auflösung nicht mit einem "normalen" uController abspielen kann. Bei 16 Bit muss der uC sehr schnell sein und die PWM Frequenz über 20kHz zu schaffen. Also wäre der richtige Weg einen PWM Prozessor zu nehmen, der dafür gedacht ist. Kennt jemand einen, der nicht gleich einen Datenblatt mit 1000 Seiten hat und mehr oder weniger Simpel in der Handhabung ist? Ich stelle mir das so vor, dass ich dem die Daten als 16Bit übergebe, und er macht mir PWM Ton daraus. Beispiel: http://www.ti.com/lit/ds/sles169b/sles169b.pdf aber er sieht mir sehr kompliziert aus. Da werden beim Layout schon 30 Fehler rein kommen, wenn man das Datenblatt davor nicht 2 Wochen studiert hat. Achja, es muss wirklich PWM sein, da die Endstufe schon PWM Eingänge hat und die kann ich nicht ändern. Danke
Ein Alesis Samplepad bekommt man fürn Hunni und muss da nix basteln. Dafür baust du sowas nicht selbst und kannst deine Samples einfach am PC auf ne SD-Karte kopieren. Ich hatte auch mit einem Selbstbau angefangen und hab den Gedanken fallenlassen als ich so ein Samplepad in die Hand bekam. Stabiles Gehäuse, gut funktionierende Drumpads, Effekte, Anschluss für Fusstaster, man kann das Teil bequem auf einem Snareständer montieren.
Am Anfang sind das nur 8 Bit mit maximal 30kHz. Das ist klar. Aber später kommt halt noch nen EEPROM und ein DAC dazu, Der Lerneffekt sollte erstens nicht fehlen und ich kann mich so langsam wieder einarbeiten. Immer Schritt für Schritt ist besser, als sich zu überfordern.
Alex schrieb: > Es sieht für mich gerade so aus, dass man den Ton in 16bit Auflösung > nicht mit einem "normalen" uController abspielen kann. Was heißt "normal"? Eine I2S/Framed SPI Schnittstelle muss er haben, und DMA wäre günstig. Ein dsPIC für 3.50€ erfüllt die Vorbedingung. > Bei 16 Bit muss der uC sehr schnell sein und die PWM Frequenz über 20kHz > zu schaffen. > > Also wäre der richtige Weg einen PWM Prozessor zu nehmen, der dafür > gedacht ist. Das sowieso. > Achja, es muss wirklich PWM sein, da die Endstufe schon PWM Eingänge hat > und die kann ich nicht ändern. Du brauchst nur einen PWM Modulator wie den hier: http://www.ti.com/lit/ds/symlink/tas5001.pdf Alles kein Problem. fchk
Freed schrieb: > Immer Schritt für Schritt ist besser, als sich zu überfordern. Das ist zwar durchaus korrekt, aber die Verwendung eines "dicken" Microcontrollers mit viel internem Flash und einer ordentlichen seriellen Schnittstelle für den Anschluss eines "dicken" Audio-DACs ist die mit Abstand einfachste Lösung. Einen eigentlich viel zu kleinen Microcontroller so zu verwenden, dass man noch mehrere externe Schnittstellen für den Datenfluss bedienen muss, ist hingegen schon wesentlich höhere Schule.
Andreas Schweigstill schrieb: > Einen eigentlich viel zu kleinen Microcontroller so zu verwenden, dass > man noch mehrere externe Schnittstellen für den Datenfluss bedienen > muss, ist hingegen schon wesentlich höhere Schule. Im späteren Verlauf möchte ich das Teil noch um einiges erweitern. Und ein µC mit 1 oder 2 MByte Flash gibt es nicht von Atmel in der 8bitter-Reihe. Damit kenne ich mich aber halt nun mal ein wenig aus und möchte das vorhandene Wissen lieber vertiefen und erweitern, statt mich komplett neu einzuarbeiten. Da hänge ich lieber nen DAC und nen Speicher an den Controller und lasse denselbigen nur die Steuer- und Durchreich-Arbeit erledigen. Das ist in ein paar Takten erledigt und sollte klappen, da mir die Formeln die genannt wurden gezeigt haben, dass es mit nem Mega8 theoretisch sogar möglich ist 16bit 44,1KHz Mono mit bis zu 10 Sekunden Länge zu erreichen jenachdem was man da für nen DAC und nen Speicher rankloppt. Von der Verarbeitungsgeschwindigkeit sollte der Controller aber locker reichen. Ich möchte mich halt wirklich ganz langsam herantasten. Atmel Studio habe ich erst mal wieder gestartet und mir Papier und Stift geschnappt um nen Ablauf der Steuerung zu planen. Erst mal nur mit Trigger und Retrigger. Das wollte ich dann morgen mit nem simplen Sample erstmal vom Mega32 in 8bit mit 30kHz abspielen lassen um ein erstes Erfolgserlebnis zu verzeichnen. Später dann weiter wie oben beschrieben. Schritt für Schritt. Ich muss eh noch passende DACs und Speicher auswählen.
Freed schrieb: > Im späteren Verlauf möchte ich das Teil noch um einiges erweitern. Und > ein µC mit 1 oder 2 MByte Flash gibt es nicht von Atmel in der > 8bitter-Reihe. Damit kenne ich mich aber halt nun mal ein wenig aus und > möchte das vorhandene Wissen lieber vertiefen und erweitern, statt mich > komplett neu einzuarbeiten. Genau DAS ist die falsche Entscheidung. > Da hänge ich lieber nen DAC und nen Speicher an den Controller und lasse > denselbigen nur die Steuer- und Durchreich-Arbeit erledigen. Die üblichen Audio-DACs, die der Rest der Welt verwendet, haben aber eine Schnittstelle, die es in Deiner kleinen, begrenzten AVR Welt nicht gibt. Du wirst sie einfach nicht anschließen können. Du wirst Dir einfach nur das Leben schwer machen, wenn Du nicht JETZT einmal einen Schnitt machst. C ist C, ob auf AVR, dsPIC33, MIPS oder ARM. Und kennst Du einen, kennst Du alle. Wichtig ist, das Prinzip zu verstehen, die Architekturen werden kommen und gehen. fchk
Naja, der o.a. Drumulator arbeitet mit einem Z80(!), hat allerdings 'ne Menge Hardware, um den kleinen Kerl bei seiner Arbeit zu unterstützen. Wenn du tatsächlich 8 Bit verwenden willst, solltest du dann über einen µLaw oder aLaw Wandler nachdenken, die den Bits andere Wichtungen als ein normaler DAC geben. Das ist bei PWM in Software machbar. Ein 20Mhz Mega32 könnte das schon reissen, allerdings ist die Verwaltung mehrerer Samples schon etwas abenteuerlich. https://en.wikipedia.org/wiki/%CE%9C-law_algorithm https://en.wikipedia.org/wiki/A-law_algorithm
Auf nen SPI-Flash 8MB kriegt man schon einiges gespeichert: http://de.farnell.com/adesto-technologies/at45db641e-mhn-y/memory-serial-flash-64mbit-udfn/dp/2414323
Peter Dannegger schrieb: > Auf nen SPI-Flash 8MB kriegt man schon einiges gespeichert: > http://de.farnell.com/adesto-technologies/at45db641e-mhn-y/memory-serial-flash-64mbit-udfn/dp/2414323 Ich bin seit ein paar Jahren auf SPANSION umgestiegen. Vorallem des Preises wegen. Und weil ich solche Sachen wie 264 Bytes/page und 2x Databuffer nie so richtig gebraucht habe. Im obigen Falle würde ich den S25FL164K0XNFI011 nehmen. http://de.farnell.com/spansion/s25fl164k0xnfi011/ic-speicher-flash-64mbit-wson/dp/2363324 1,18 EUR anstelle von 5,58 EUR.
Müsste ich sowas realisieren, würde ich ein fertiges Board nehmen und dann nur noch ein Interface zu Deinen Sensoren/Triggerquellen dran bauen: BeagleBoard: http://beagleboard.org/ http://de.wikipedia.org/wiki/BeagleBoard oder Raspberry PI: https://www.raspberrypi.org/ http://de.wikipedia.org/wiki/Raspberry_Pi Da lässt sich dann für künftige Erweiterungen einfach auch mal ein Monitor/Tastatus/Maus etc. anschliessen und dank Netzwerkfähigkeit ergeben sich auch noch viele schöne Möglichkeiten (Samples von einem Server nachladen, speichern von Samples, etc.).
:
Bearbeitet durch User
Haben die Drumcomputer auch eine Anschlagsdynamik? Dann musste man noch einen AD Wandlung pro Trigger durchführen.
Thomas O. schrieb: > Haben die Drumcomputer auch eine Anschlagsdynamik? Zumindest die besseren ja. Mit den richtigen Pads erkennen die auch den Anschlagspunkt auf dem Pad und spielen unterschiedliche Klänge ab.
Ich verstehe nicht so ganz, warum ich jetzt unbedingt auf nen größeren Prozessor oder gar ne andere Programmiersprache umsteigen sollte... Wenn ich korrekt geschätzt habe müsste doch bereits ein kleiner Tiny2313 dazu imstande sein 44.100 Mal pro Sekunde 2 Byte von einem SPI zu einem anderen zu schicken, wenn man alles in Assembler ohne Nutzung des Hardware-SPI macht. Daher der externe DAC und EEPROM/Flash. Und 16bit DACs mit SPI gibt es. Habe ich bereits nach gesucht und einige gefunden. Bekomme morgen erstmal nen 12bitter. Schauen wie sich das anhört...
Freed schrieb: > Ich verstehe nicht so ganz, warum ich jetzt unbedingt auf nen größeren > Prozessor oder gar ne andere Programmiersprache umsteigen sollte... > Wenn ich korrekt geschätzt habe müsste doch bereits ein kleiner Tiny2313 > dazu imstande sein 44.100 Mal pro Sekunde 2 Byte von einem SPI zu einem > anderen zu schicken, wenn man alles in Assembler ohne Nutzung des > Hardware-SPI macht. Sicher, das kannst Du irgendwie hinpfuschen. Aber Deine SPI-DACs sind keine Audio-DACs; da gibts nämlich klitzekleine Unterschiede. Und die Audio-DACs haben eben kein SPI, sondern Framed SPI. Auch das könntest Du hinfrickeln, aber ohne Jitter wird das wohl nicht abgehen. Anders gesprochen: Du machst unheimliche Klimmzüge, um aus Scheiße Schokolade zu machen. Aber auch wenn die Farbe einigermaßen hinkommt - den Geschmack wirst Du nicht treffen. Natürlich bist Du nicht erfahren genug, um die Folgen von Designentscheidungen zu überblicken. Das ist keine Schande. Beratungsresistenz ist eine. fchk
Frank K. schrieb: > Sicher, das kannst Du irgendwie hinpfuschen. Aber Deine SPI-DACs sind > keine Audio-DACs; da gibts nämlich klitzekleine Unterschiede. Sicher, und jeder Audiophile kann die natürlich heraushören. Bloß nicht im Doppel-Blindtest, das sind ja auch völlig unfaire Testbedingungen, wenn man nicht vorher weiß, was zwingend das Bessere sein muß...
...Nachtrag zu meinem Post weiter oben. Das BeagleBone Black hat nur HDMI zur Ausgabe von Audio (und Video). Falls Analogaudio benötigt wird, gibts das Zusatzboard "SoundsCape": https://www.kickstarter.com/projects/148675608/soundscape-analog-and-bluetooth-audio-for-beaglebo?ref=live Da ist ein ADAU1361 von Analog Devices drauf, welcher Deinem Bedürfnis nach möglichst guter Soundqualität nachkommt. http://www.analog.com/en/products/audio-video/audio-codecs/adau1361.html
Frank K. schrieb: > Auch das könntest Du > hinfrickeln, aber ohne Jitter wird das wohl nicht abgehen. Das würde ich so allerdings nicht unterschreiben - ein Tiny ist durchaus in der Lage, ein beinhartes komplexeres Timing hinzubekommen, die VGA und PAL Generatoren zeigen, das so etwas geht. Ein I2S oder SPI Signal ist ja nun auch kein Hexenwerk und lange nicht so schnell wie PAL oder VGA. Das man dazu ein wenig Hirnschmalz braucht, ist auch klar. . Der kleine MC hat seine Grenzen eher in der Verwaltung grosser Speicher und dem Zugriff darauf mit geringer Latenz und er hat eben sehr wenig Buffer, um daraus einen sauberen gleichmässigen Datenstrom zu produzieren. Sicher wird auch das Mischen bzw. gleichzeitige Spielen mehrere Samples nicht gut klappen, denn die Rechenoperationen werden die kleine Kiste schnell an die Grenzen bringen. Als Einstieg würde ich vermutlich erstmal einen kleinen Sinusgenerator aus dem Tiny machen, der ganz simpel eine Tabelle auf den DAC spult.
c-hater schrieb: > Sicher, und jeder Audiophile kann die natürlich heraushören Das kann wirklich jeder Laie, diese DACs nicht wirklich nicht 100% Audio-tauglich. Es gibt aber aus der asiatischen Ecke in der Bucht einige fertige Converter I2S-2-DAC mit sehr guten Ausgängen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.