Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7502 discussions

Re: [LAD] ALAC codec being added to libsndfile

by Erik de Castro Lopo

Georg Holzmann wrote: > Hallo! > > > The only real problem I've had doing it is finding time to work > > on it. Fortunately I am pretty sure I will find time to work on > > this between xmas and new year. > > Thanks for the answer! > If you need any testing or something else let me know! Hi Georg, Support for 16 bit ALAC is in Git at: https://github.com/erikd/libsndfile Support for other bit widths will be added in the near future once I know the 16 bit stuff is working. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

13 years, 4 months

OSC sequencer idea (was: Qtractor 0.5.4 - Echo Victor shouts out!)

by Stephen Sinclair

It seems this debate is how to represent OSC messages in a sequencer. I've thought about this before, and the idea I always had in my head was something tracker-like, where you would assign columns (or rows..) to a message path, and specify whether the arguments are ints, floats, etc. For each argument the column would contain subcolumns with fields allowing editing of these values. Any row that is all "nil" would mean "do not send a message." The editor might allow a special column type called "note" which is represented on-screen as a note name (A#3 or whatever) but sends out the value as an integer or float. Alternatively the editor could be told the min/max values of the subcolumn and represent it as horizontal bars or a line plot, etc. I even started working on such a thing once, with the intention of controlling sequences for custom synths written in e.g. Chuck or PureData. However, I never got far with it as I had other things to do. In any case, in this paradigm, the user would define a patch in Pd (or....) which accepts certain control or trigger messages, and therefore the sequencer would need to be told what messages to send it. No need to "standardize" the messages for any particular representation, since it would be different for each patch anyways. (The "sequence + patch" would be considered together as the music file.) What I like about this is that it would allow a user to use whatever program he/she wants for sound synthesis, but have keep a consistent sequencer interface. You could even use multiple back-ends for sound synthesis in the same track. p.s. thanks Jonathan for bringing up libmapper. For those who don't know, libmapper is an attempt to create a "glue" layer for OSC-supporting programs. Instead of standardizing on a set of messages, the idea is to instruct sending programs to translate their messages into the format required by the receiver, including any data transformation (scaling, etc). This allows programs to use any message names they want, keeping the usefulness of readable, program-specific semantic naming schemes, while still being able to connect to each other. Still under heavy development, but it's quite functional, web site is at http://libmapper.org Steve On Sun, Mar 4, 2012 at 4:27 PM, Albert Graef <Dr.Graef(a)t-online.de> wrote: > On 03/04/2012 06:32 PM, David Robillard wrote: >> >> What do you mean by "pick the OSC addresses that I want"? > > > I mean those symbols with the slashes that are the first part of any atomic > OSC message like /foo/bar 4711.0. Usually such a symbol would denote the > particular control that the value applies to. When using OSC as input to or > output from automation, obviously I'd have to specify which OSC addresses I > want to be mapped to which automation parameter. > > However, I'd actually prefer a kind of separate OSC track which would be > connected to OSC inputs and outputs and listens for all OSC messages on its > OSC inputs, no matter what the addresses are. So (an ASCII representation > of) the contents of such a track might look like > > # delta OSC addr value > 0 /foo/bar 0.78 > 10 /reverb1/wet 0.3 > 5 /foo/bar 0.66 > etc. etc. > > By these means the OSC track would just record any messages that it receives > on its inputs, and I might then map them to the appropriate automation > parameters on other (audio and MIDI) tracks in the DAW, or just have them > played back via the OSC outputs assigned to the track, in order to drive > some other application like Pd. > > Dave, will you be at LAC in April? I'd really like to discuss this in more > detail with you, but it's much easier to do this in a room together and with > a whiteboard and a data projector within reach. ;-) If there's enough > interest, maybe we could do a "control beyond midi" brainstorming session at > LAC? Maybe Rui wants to join us there, and I know that some guys at CCRMA > are also interested in this. I guess that the organizers can allocate us a > time slot and a room with the necessary equipment if we just ask for it. > > Albert > > P.S.: Rui, apologies for hitchhiking your thread. I hope that you will > forgive me over a glass of good Californian wine. ;-) > > > -- > Dr. Albert Gr"af > Dept. of Music-Informatics, University of Mainz, Germany > Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de > WWW: http://www.musikinformatik.uni-mainz.de/ag > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev

13 years, 4 months

preset saving in sessions

by parched2099

With the advent of NSM, there's a better chance than ever for autoloaded sessions when working. One of the challenges of autoswitching between sessions is loading presets for that session. In, for example LV2rack, it starts, but presets have to be loaded manually, after it gets going. Is there a mechanism for LV2rack, and other standalone plugin hosts, to have a preset automatically load with the selected preset for a session, when that session is selected? An example is lv2rack with the IR lv2 plugin, which i've been testing in NSM. LV2rack comes up ok, but the preset i've built for a specific session doesn't automatically load. I assume this is the case when using something like LV2rack in other session managers too. Where would a call for an autoloaded session saved preset come from? The session manager, or LV2rack itself?

13 years, 4 months

Re: [LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out! (Emanuel

by Jeff McClintock

> The chance for MIDI to improve seems very low, due to its technical > limits. HD-Protocol MIDI is coming, albeit with painfully slow progress. Best Regards, Jeff

13 years, 4 months

[ANN] Non DAW and Non Mixer 1.1.0 (now with NSM)

by J. Liles

Greetings, I'm pleased to announce the release of Non-DAW and Non-Mixer version 1.1.0. It's been a while since the last release. But, I assure you, the project is still alive and well. This release includes a number of fixes and some minor improvements to the build system. The big changes are: * Enhancements to the spatialization controls (which are automatically provided for Ambisonics plugins). * Support for the Non Session Manager. * Enhancements to Control Sequences, OSC control signals can be sent from Non-DAW to Non-Mixer. These connections will be preserved in the session. * Non-Mixer accepts input for all Module/Plugin controls via OSC. * Non-Mixer can now import and export individual strips (including the chain of modules and all their parameters!) This allows a workflow on a higher level than presets. * Updated visual styles for both Non-Mixer and Non-DAW. The 'Flat' style has been greatly improved. * New knob styles for Non-Mixer and knob style is a configuration option rather than requiring editing the source. * New icons in an assortment of sizes. Additionally, Non now supports a robust new session management protocol called NSM. A session management daemon is provided along with a graphical interface called Non-Session-Manager. NSM represents a significant leap forward for session management in Linux audio. :: History of NSM Way back in 2008, I became frustrated with the state of the art of session management on Linux (a situation which has improved only incrementally since that time). I ditched support for LASH, wrote a lengthy post about Non-DAW's session management requirements to the LAD mailing list, and started managing my sessions with shell scripts and jack_snapshot. This eventually evolved into a session manager written in Unix shell and using Unix FIFOs and regular files for client control/communication. This system of session management was tentatively called NASH (Non Audio Session Handler) and was never released. In 2010, shortly after the release of Non-Mixer, I devised a prototype version of the NSM OSC API and have been using it, still unreleased and in prototype form, since then. The 2010 implementation did not have a user interface and was controlled via shell scripts using the `send_osc` command included in the distribution. Then, in 2012 (4 years later!), I was contacted by an enthusiastic power-user regarding implementing OSC support in Non-Mixer. Since NSM uses OSC for server<->client communication, I already had much of the OSC work done and figured I might as well release it--and, while I was at it, NSM. I then endeavored to simplify and document the NSM API, discussing it at length with, and taking many suggestions from, Nedko Arnaudov, the LADISH author. After implementing the Non-Session-Manager FLTK GUI to control the session management daemon, a new release became inevitable. :: Bullet Points for NSM: * Extremely fast and responsive control mechanism and user interface. * The only dependency for clients and server is an OSC library (I use liblo). * Smart clients are able to switch projects without restarting. * Clients can provide real-time status feedback to the server, and therefor the user. * The server stores all session data in per-session directories under a configurable session root. * Clients are forbidden to save or open files outside of the per-session directory. * The server provides simple template support in the form of whole-session duplication. * The Session management daemon is fully controllable via OSC. * Strict user interface guidelines for a uniform and predictable experience. * The abstract session management API has no architectural requirement for JACK, Xorg or any other subsystem (other than UDP networking). This means that both headless daemons and programs which are not JACK clients can be managed together in the same session. * A single session can be distributed across multiple machines on a network. * Multiple, independent, sessions can be opened on one machine at the same time. :: More About the NSM API The latest NSM API documentation can be found at: http://non.tuxfamily.org/nsm/API.html NSM is included in the Non-DAW/Non-Mixer repository. :: Ongoing and Future Development Features that are in development for future releases include an auto-learning and graphically re-mappable JACK MIDI<->OSC gateway program tentatively named Non-OSC-MIDI-Mapper, which will simplify the connection of bidirectional control surfaces such as the BCF2000 to Non-Mixer. This program relies on Non's generic Control Signal layer on top of OSC. So it's not necessarily generally useful (although, in the future, it may be possible to use the `libmapper` library to provide the same functionality in a somewhat standard way). LV2 support is a frequently asked question. For various reasons, I currently have no plans to host LV2 plugins in Non-Mixer. But if anyone can come up with a compelling argument for LV2, or name one existing (libre) LV2-only plugin which couldn't be ported to LADSPA in a few hours that I couldn't live without having in Non-Mixer--I'd love to hear about it. I plan to re-factor Non-Sequencer to use the `nonlib` library common to Non-DAW and Non-Mixer. This will eliminate some duplicated code and allow for some of the user interface improvements seen in Non-DAW to be implemented for Non-Sequencer. It will also enable various forms of MIDI support in Non-DAW/Non-Mixer (it's not clear yet what forms this support might take.) Similarly, by using nonlib, OSC will be available in Non-Sequencer, probably taking the form of OSC control for pattern triggers and possibly pattern input. Also, with NSM's 'broadcast' capability, the holy grail of a shared tempomap is closer than ever. Another long-term goal for Non-Sequencer is to make the interface more compatible with touchscreen use, which I am better equipped to tackle now that I have a tablet like computer to play with. A near term goal for Non-Mixer is to add an option to that causes all mixer strips to run in a single JACK client. Conceptually, this is a horrible idea, but due to some practical performance limitations of JACK which affect users with hundreds of mixer strips, it may be a necessary evil. Leave it to JACK to design and advertise a feature (multiple clients per process) and then turn around and antagonize the people who actually use it. :: Project Notes Please keep in mind that the Non project is a one man show. I designed and implemented all of this stuff by my self, and at a considerable cost in time, sleep and energy. I make it available to you so that you can be free of the enormous burden of having to solve these complex problems yourself. I see chatter on various forums about forking the project, the project being dead, etc. Unlike some of the more heavyweight projects out there, Non has no corporate sponsor, and I have a complicated and turbulent existence which does not always allow me to devote my attention to purely intellectual pursuits. I welcome any and all contributions, whether they be in the form of code, documentation, testing, package maintenance, chocolate, roses, precious metals, priceless relics--whatever. If those who bring up the issue of forking really had the skill and energy required to do something better with Non-*, you'd think they'd at least try submitting a few patches to me first... I run Debian GNU/Linux and Non-* use a made-from-scratch custom build system which relies on accurate information from pkg-config. I cannot test on, or anticipate the quirks of, the hundreds of other Linux distributions out there. I have a policy of never committing code to the Non git repositories which does not build. Thus, if you are having a problem building Non on your system, chances are it's just because of some silly/simple quirk of the distribution you're using that could easily be fixed. However, I'm not going to scour the web looking for these reports. Unless you send a report to the appropriate Non-* mailing list, expect that your issue will never be resolved. As always, the best and fastest way to get anything fixed is to just fix it yourself and sent me the patch--preferably with a thorough explanation in the commit message of why it is needed and how it works, as the less time I have to spend reviewing a patch, the quicker it will be applied. And finally, a note to packagers: If you feel that there's something about Non's build system that you don't understand or feel like you have to hack around, please consider discussing it with me. I'm more than willing to make changes to the build system which make life easier for packagers and improve the quality of packages. Having flaky builds of Non-* in a distribution's packages isn't good for anybody. I've seen comments in distributions' packaging bugtrackers saying that Non is a dead project, that the "developers" (plural) are unresponsive etc. But I've never heard from these people. If they actually took the time to email me, they might have different opinions. :: Errata I do not recommend linking Non-DAW against FLTK 1.3.0. FLTK 1.3.0 introduced a number of bugs, one of which seriously impairs Non-DAW's graphics performance. Non-Sequencer and Non-Mixer do not use the features of FLTK that have become buggy, so if you only plan to use them 1.3.0 should be fine. 1.1.10, 1.1.9, and 1.1.7 work fine, however. In the future, I'll be maintaining a known-working version of FLTK along with the Non repository so that Non-* can be statically linked to the custom FLTK and avoid problems like this--and also allow many workarounds used by the Non-* programs to be removed in preference to fixing them at their source. If you decide to build FLTK yourself, don't forget to use the following configure options: --enable-threads --enable-shared --enable-xft --enable-xdbe ----- Non-DAW and Non-Mixer (and Non-Sequencer) can be acquired via git from the URLs listed on the Non website: http://non.tuxfamily.org ----- The shortlog from v1.0.0 to v1.1.0 follows: Jonathan Moore Liles (114): Mixer: Don't use Fl_Group::clip_children(), which was only made public in FLTK 1.1.10. Fix a 64-bit bug in LADSPAInfo. Fix another 64-bit bug in Module insertion. Fix a mismerge that caused meter indicators not to be updated. FL: Clip drawing of value of FL_Sometimes_Input when in non-input mode. Mixer: Set minimum size for main window. Mixer: Fix automatic row layout logic. Mixer: Don't die if user picks a submenu node in module context menu. Mixer: Destroy a module's parameter editor window when the module itself is destroyed. FL: Get rid of unnecessary call to clip_children(). Move non-daw scripts into timeline/ tree. Mixer: Save/load the control mode status of the gain controller as part of the mixer strip's state. Mixer: Improve spatializer appearance. Mixer: Report azimuth and elevation of panner points. Mixer/Module_Parameter_Editor: Automatically show panner control for module parameter pairs named Azimuth and Elevation. Mixer/Panner: Vary width of latitude lines. Module Parameter Editor: Don't use local allocation to store label. Mixer: Further improve the appearance of the Panner widget. Mixer: Fix azimuth/elevation reporting. Load current values in Module_Parameter_Editor. FL/Fl_Scalepack: Give scalepack the ability contain a resizable() child. Mixer/Mixer: Cleanup. Mixer: Auto-connect spatializer controls to spatialization plugins. Mixer: Cleanup. Mixer/Panner: Fix azimuth assignment. Make spatialization mode of controller_module more robust. Mixer/Module_Parameter_Editor: Don't point widow label at stack allocation. Mixer/Module_Parameter_Edtior: Silence compiler warnings. Mixer: Raise (arbitrary) maximum number of channels of JACK module from 6 to 16. Mixer: Fix callback delivery by Controller Module. Timeline: Fix 64-bit bug in interactive region trimming. Fix 64-bit bug in peakfile handling. Mixer: Explicitly link to libdl. Fix build being broken by some include defining a preprocessor macro for 'None' Mixer: Don't segfault when removing a module. Mixer: Don't segfault during teardown upon WM initiated exit. Mixer: Handle WM main window close event just like Quit menu comment (confirm save). Some distributions put --as-needed in pkg-config and fltk-config results. *See you in /dev/null* Some distributions put --as-needed in pkg-config and fltk-config results. *See you in /dev/null* Really. I do. Don't rely on 'Fl' symlink which only exists on Debian. Mixer: Add basic OSC support. Mixer: Add basic OSC control to Controller_Module. Mixer: Add commandline option for specifying the OSC port to use. Mixer: Allow clients to query for available OSC paths. Mixer: Ensure that JACK_Module passes chain_name_changed event to its Controllers. Mixer: OSC enhancements. Responsd to both exact (range limited) and Control Voltage (0.0-1.0 on */cv) input. Mixer: Make OSC ports a property of Module::Port, not Controller_Module. Therefore, all plugin parameters will be accessible via OSC. Mixer: Create unique OSC paths even when multiple instances of a module/plugin with the same name exist in a chain. OSC: Don't swallow up all parameterless messages. Mixer: Feedback control values to OSC senders. Mixer: Default OSC paths are CV. Use /unscaled for exact input. Mixer: Don't create/destroy OSC ports more often than necessary. Mixer: Update OSC paths upon chain/strip name change. Mixer: Add OSC section to documentation. Mixer: Display realtime parameter changes (initiated via automation or GUI) in Module_Parameter_Editor Mixer: Cleanup OSC value scaling/clamping behavior. Mixer: Fix behavior issues of Toggle controls. Mixer: Don't allow ',' in OSC paths. Mixer: Fix mirroring and OSC automation of Spatialization controls. Implement the Non-Session-Manager (NSM) Mixer: Fix GUI update on Controller_Modules being controlled via JACK CV. Mixer: Destroy instances of Controller_Module when the connected modules are removed. NSM: Process more than one message per wait cycle! NSM: Detect death of clients whose processes are not children of NSMD. NSM: Update documentation. NSM: Fix logic when waiting for clients to load. NSM: Support sessions spread across multiple servers. OSC: Process all available events in one wait cycle. Give Non-DAW the ability to detect Non-Mixer OSC servers via NSM broadcast handshake. OSC: Implement generic signal model with path auto discovery through NSM. NSM: Mutli-server fixes. Timeline: Don't die when not running under NSM. Mixer: Don't die when not running under NSM. FL: Fix an uninitialized value. Mixer: Fix an invalid read on strip destruction due to a missing lock. Don't poll NSM as frequently. NSM: Clients must use the same protocol (UDP,TCP) as NSM server. Timeline/Track: Avoid unnecessary drawing of occluded track box. Timeline: Add interpolation mode choice of Linear and None to Control Sequences. OSC: Save and restore OSC signal connections outgoing from Non-DAW. Timeline: Run OSC output in a dedicated thread. Timeline: Clock cleanup. OSC: Signal cleanups. OSC: Improvements to signal routing. Add libsigc++ as a dependency. Big OSC signal cleanups NSM: Add --detach option to nsmd. NSM: Add session locking to nsmd. NSM: Minor GUI enhancements. NSM: Don't forget to inform GUI of the removal of stopped clients when closing a session. OSC: Fix signal creation notification. Cleanup compiler warnings. NSM: Time client responses. Update documentation. Mixer: Document spatialization control for Ambisonics plugins. Mixer: Update documentation. scripts: Allow suggested packages. Everybody gets new icons! Also, .desktop files. Use getopt_long for processing command line arguments to Non-DAW and Non-Mixer. NSM: For lack of a better place to put it, add 'jackpatch' program to the repository. NSM: Minor cleanup. NSM: Update documentation. Add notes to packagers. Add 'gleam' inspired boxtypes to replace the ones in the gtk+ theme. Also, tweak crystal boxtypes. Mixer: Add new 'plastic' knob type. Make knob type to display configurable. GUI tweaks. Mixer: Try harder to avoid drawing meters more than necessary. Timeline: Work around bug in FLTK 1.3 when drawing a string containing only symbols. Mixer: Make slider types optional too. Timeline: Warn about buggy FLTK version. Mixer: Try to fix some weirdness with Controller Module knob display. Mixer: Implement mixer Strip import/export Update Non-DAW screenshot in documentation. Bump versions.

13 years, 4 months

Re: [LAD] audio on Raspberry PI

by Victor Lazzarini

Thanks, sounds good, I am thinking here: cheap synthesizer. Victor On 29 Feb 2012, at 10:40, James Harrison wrote: > Comes with a DAC, but no ADC as far as I can see. > > Cheers, > James Harrison > > > On 29/02/2012 10:30, Victor Lazzarini wrote: >> Does anyone know whether the Raspberry PI comes with a DAC/ADC? >> >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> _______________________________________________ >> Linux-audio-dev mailing list >> Linux-audio-dev(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie

13 years, 4 months

memory allocation for the real time thread, opinions wanted

by Iain Duncan

Hi everyone, hoping to get opinions from gurus on here, who have been *incredibly* helpful in getting my project to where its at. A million thank yous! Ok, the situation so far, which is working well: - the app uses a generalized 'message' structure, all the different forms of messages fit into this structure by having it act alike a union. ( ie, a message always takes up the same amount of space, no matter the type ) - messages do not container pointers, in order that they be simple to send and receive over network clients, hardware, etc - there are ringbuffers between my audio thread and real time thread What I'm tackling: - I want to add the capability for messages to have deferred execution, so they can be sent with a 'process at 4:3:1' kind of thing - I think the best tradeoff for my app so far will be to use a hybrid of a timeline array and a linked list. there will be coarse time values stored by raw array indexing, speeding up lookup, and fine time values will be stored in the messages themselves - so, when the engine is processing deferred messages, it will go and check timelineArray for all messages at bar 1:beat 1, which will be a linked list of all the messages with start time between bar:1 beat 1 and bar 1: beat 2 ( time resolution may change, this just for example - then the engine iterates on every tick through that list of messages. This way, iteration on every tick is limited to a reasonable sized linked list and I can play with the cpu vs data storage equation by simply changing the resolution of the time line array Issues: - I need to allocate memory for new linked list items in the realtime thread - the timeline array needs to be able to grow in the real time thread Thoughts: - I don't need to get it perfect *right now* but I need to be able to change it to Really Good later - I checked out some resources, like this one the Design Patterns for *Real* -*Time* Computer *Music* Systems<http://www.google.ca/url?sa=t&rct=j&q=audio%20allocating%20memory%20in%20re…> and the supercollider book chapter and see there are a lot of options - I could pre-allocate a giant list of messages and pluck the data off that list when I need to make a new one - I could pre-allocate a block of memory and allocate off that - I could allocate in the non-realtime thread and then pass memory over in queues. Would love to hear opinions on how others would solve these, including tradeoffs of each. thanks! iain

13 years, 4 months

Music made with Linux: Airship - A 16bit Soundtrack Theme

by Nils

Hello list, I would like to share a piece I've just finished. The original blog entry is here, but for your convenience I'll include a copy into this mail. Feel free to use any channel you want if you would like to comment on it. http://www.nilsgey.de/2012/02/29/airship-theme/ Airship - A 16bit Soundtrack Theme direct download: http://www.nilsgey.de/uploads/NilsGey-AirshipTheme.mp3 I have finished my first just-for-fun composition since a very long time ago. It is a game-soundtrack like piece I named “Airship”. I can imagine this in a Japanese 90’s RPG from the SNES or Sega Genesis/MegaDrive era. Software used: Laborejo composition and midi generation, Fluidsynth for midi to wave rendering and Ardour for the fadeout :) . I used an .sf2 called Setzers SPC which I have downloaded here. I am not sure about the soundfonts legal status so I am careful and release the Airship Theme not as a free piece but just as: Listen to it freely, share and redistribute it but don’t use it in any work, derived or original, or as part of a game or video etc. Don’t do anything commercial with it and don’t change the mp3 tags. If you find a named, matching License to this description feel free to use that instead. I would be very happy if you leave a comment or click this blogs “Like” button. Greetings, Nils http://www.nilsgey.de http://www.laborejo.org

13 years, 4 months

Re: [LAD] audio on Raspberry PI

by Victor Lazzarini

If there is Linux and Alsa, we should just be able to cross-compile (or even compile on the Raspberry if there is gcc); I don't see many difficulties. It should be easier than android and iOS. I might see if I can get one to run Csound on. Regards Victor On 29 Feb 2012, at 10:46, James Harrison wrote: > I'm hoping that adding an ADC won't be too tricky, though it has USB so a USB sound card should work. For $25 an end, it'd make a lovely portable IP codec for broadcast with CELT and RTP... > > Cheap synth would be neat, though. Wonder how much stuff in the Linux audio world is ARM-compatible? > > Cheers, > James Harrison > > > On 29/02/2012 10:45, Victor Lazzarini wrote: >> Thanks, sounds good, I am thinking here: cheap synthesizer. >> >> Victor >> On 29 Feb 2012, at 10:40, James Harrison wrote: >> >>> Comes with a DAC, but no ADC as far as I can see. >>> >>> Cheers, >>> James Harrison >>> >>> >>> On 29/02/2012 10:30, Victor Lazzarini wrote: >>>> Does anyone know whether the Raspberry PI comes with a DAC/ADC? >>>> >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> Dept. of Music >>>> NUI Maynooth Ireland >>>> tel.: +353 1 708 3545 >>>> Victor dot Lazzarini AT nuim dot ie >>>> >>>> >>>> >>>> _______________________________________________ >>>> Linux-audio-dev mailing list >>>> Linux-audio-dev(a)lists.linuxaudio.org >>>> http://lists.linuxaudio.org/listinfo/linux-audio-dev >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> _______________________________________________ >> Linux-audio-dev mailing list >> Linux-audio-dev(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie

13 years, 4 months

audio on Raspberry PI

by Victor Lazzarini

Does anyone know whether the Raspberry PI comes with a DAC/ADC? Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie

13 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev