Linux-audio-dev June 2003

linux-audio-dev@lists.linuxaudio.org

85 participants
85 discussions

by Christian Schoenebeck

Hi! I have ported Sebastien Metrot's libakai to Linux some couple of weeks ago. Until it will be in CVS one day you can get it from: http://stud.fh-heilbronn.de/~cschoene/projects/libakai/ I added some code to the demo application to extract samples from a Akai disc yesterday, so you can now actually not only see but also hear what's on a disc. You will notice that there's still a small bug, I will fix it ASAP, but I won't complain if someone else will look for it ;) Best regards. Christian

21 years, 6 months

[linux-audio-dev] [OT] Question about some definition..

by Juan Linietsky

Hi! i'm doing some studying on dsp, and one thing I could never properly understand is the term of "excitation signal" I seem to find it associated to environment or natural sources, but I cant really find a definition. Could someone with enough knowledge on this subject please give me a brief on this? Thanks in advance! Juan Linietsky

21 years, 6 months

[linux-audio-dev] JACK 0.72.4 released

by Taybin

JACK 0.72.4 JACK is a low-latency audio server, written primarily for the GNU/Linux operating system. It can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. Its clients can run in their own processes (ie. as normal applications), or can they can run within the JACK server (ie. as a "plugin"). JACK is different from other audio server efforts in that it has been designed from the ground up to be suitable for professional audio work. This means that it focuses on two key areas: synchronous execution of all clients, and low latency operation. **CHANGES** * Updated documentation * Bug fixes * MacOSX port. Includes a ProjectBuilder file to help compilation. Requires PortAudio to be installed. * Ringbuffer example files added * New example client: simple transport master to demonstrate Jack's transport API. Requires GNU readline to compile. * Removed software monitoring and improved hardware monitoring semantics. Taybin Rutkin

21 years, 6 months

Re: [linux-audio-dev] 8bit sound wav playing to a 16bit sound card...

by Derrick

> I think someone else (Paul?) hit it on the head. I fyou load 2 8bit > samples and pass them to a soundcard that is expecting 16-bit samples, > you'll get a LOT of garbage - like white noise - and it will be 1/2 as long > as your input sample. > > See, each pair of 8 bits will become a 16 bit sample. > > input 8 8bit samples: > dec: 0 64 127 64 0 -64 -127 -64 > hex: 0x00 0x40 0x7f 0x40 0x00 0xc0 0x81 0xc0 > > read as 4 16bit samples (ignore endianness): > hex: 0x0040 0x7f40 0x00c0 0x81c0 > dec: 64 32576 192 -32320 > > > Notice how the waveforms don't resemble each other at all. > > > Clearer, now? I See.. So if I wanted to convert to a 16bit, how would you recommend I do this? It would seam I would need some type of Filler.... err. white noise or just blank noise to fill in the extra 8bits. I guess I could convert every bit read from the file from an 8bit (unsigned char) to a 16bit (signed short) then write it to the /dev/dsp? Bare with me here, I'm not a verteran.. So I would have to convert the unsigned char to a signed char, then to a signed short... So Not knowing how the conversion is done in the OS, I'm assuming that the resulting signed short would be padded with 'off' bits. which would come out as silence correct? ( but it's in the same sample, so you really wouldn't hear the silence ) Werd? -- It looked like something resembling white marble, which was probably what it was: something resembling white marble. -- Douglas Adams, "The Hitchhikers Guide to the Galaxy"

21 years, 6 months

[linux-audio-dev] NI Traktor

by Robert Jonsson

This is a first for audio applications. Native Instruments Traktor just appeared on Freshmeat! :) I guess some people are starting to take notice of the OSS community. Though it isn't OSS in itself and not available for Linux (OS X, + a few marginal os:es). But the most interesting thing was that they used Freshmeat as a marketing channel. /Robert

21 years, 6 months

[linux-audio-dev] System Exclusive question

by Chris Wareham

Hi, I'm trying to write a patch editor and librarian for Roland's CM-32L synth module. This was a repackaged version of the popular MT-32 with 8 part multimbral support, separate drums and a basic reverb facility. The only controls on the front panel are a power switch and master volume knob - everything else has to be done via MIDI. I have written a simple program to change which preset each part uses, and can also trigger notes. Now I want to get a SysEx dump so I can put together the patch editor. However, whenever I send a Request Data message the unit doesn't appear to respond. It definitely receives the message as the MIDI activity light comes on. But when I try to read from the MIDI device file my call blocks forever. Has anyone had succes in getting SysEx data flowing back and forth between Roland sound modules and their computer? I have attached my simple test program in case I'm doing something obviously wrong. By the way, I'm working on NetBSD which has slightly different MIDI device filenames to Linux. Chris -- http://www.btinternet.com/~chris.wareham/ /* get_sysex_dump.c * cc -Wall -Wformat -g -o get_sysex_dump get_sysex_dump.c */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <fcntl.h> #include <unistd.h> #define SYSEX_START 0xf0 #define SYSEX_END 0xf7 struct sysex { unsigned int length; unsigned char *data; }; static struct sysex *sysex_new(void); static void sysex_delete(struct sysex *); static void sysex_set_length(struct sysex *, unsigned int); static void sysex_read(int, struct sysex *, int); static void sysex_write(int, struct sysex *); static int sysex_checksum(struct sysex *, int, int); int main(int argc, char *argv[]) { int fd, i; struct sysex *se; fd = open("/dev/rmidi2", O_RDWR|O_SYNC); if (fd == -1) { fprintf(stderr, "open() failed: %s\n", strerror(errno)); return 1; } se = sysex_new(); sysex_set_length(se, 11); se->data[0] = 0x41; /* Roland's ID */ se->data[1] = 0x10; /* Device Number - default appears to be 0x10 */ se->data[2] = 0x16; /* Model ID */ se->data[3] = 0x11; /* Command ID - "Request Data" */ se->data[4] = 0x04; /* Address MSB */ se->data[5] = 0x01; /* Address */ se->data[6] = 0x76; /* Address LSB */ se->data[7] = 0x00; /* Size MSB */ se->data[8] = 0x01; /* Size */ se->data[9] = 0x76; /* Size LSB */ se->data[10] = 0x0e; /* Checksum */ sysex_write(fd, se); sysex_set_length(se, 252); /* 8 bytes to wrap data, and 246 bytes of data */ sysex_read(fd, se, 1); printf("Read %d bytes\n", se->length); for (i = 0; i < se->length; i++) printf("0x%0x\n", se->data[i]); sysex_delete(se); if (close(fd) == -1) { fprintf(stderr, "close() failed: %s\n", strerror(errno)); return 1; } return 0; } /* Receives a MIDI System Exclusive message */ void sysex_read(int fd, struct sysex *se, int autostop) { int n, length = 0; unsigned char c; if (fd == -1) { fprintf(stderr, "sysex_read() failed: invalid fd\n"); return; } if (se == NULL) { fprintf(stderr, "sysex_read() failed: null sysex argument\n"); return; } while ((n = read(fd, &c, 1)) == 1 && c != SYSEX_START) usleep(40); if (n != 1) return; while (length < se->length) { n = read(fd, &c, 1); if (n == 1) { se->data[length++] = c; if (autostop && se->data[length - 1] == SYSEX_END) break; } } if (length < se->length) { se->length = length; se->data = realloc(se->data, se->length); } } /* Sends a MIDI System Exclusive message */ void sysex_write(int fd, struct sysex *se) { unsigned char *data; if (fd == -1) { fprintf(stderr, "sysex_write() failed: invalid fd\n"); return; } if (se == NULL) { fprintf(stderr, "sysex_write() failed: null sysex argument\n"); return; } data = calloc(se->length + 2, sizeof(unsigned char)); data[0] = SYSEX_START; memcpy(data + 1, se->data, se->length); data[se->length + 1] = SYSEX_END; write(fd, data, se->length + 2); free(data); } static struct sysex *sysex_new(void) { struct sysex *se; se = calloc(1, sizeof(struct sysex)); return se; } static void sysex_delete(struct sysex *se) { if (se->length != 0) free(se->data); free(se); } /* Sets the length of a MIDI System Exclusive message */ void sysex_set_length(struct sysex *se, unsigned int length) { if (se == NULL) { fprintf(stderr, "sysex_set_length() failed: null sysex argument\n"); return; } se->length = length; se->data = realloc(se->data, se->length); } /* Determine a Roland System Exclusive checksum */ int sysex_checksum(struct sysex *se, int start, int length) { int checksum, i; if (se == NULL) { fprintf(stderr, "sysex_checksum() failed: null sysex argument\n"); return 0; } checksum = 0; for (i = start; i < start + length; i++) { checksum += se->data[i]; if (checksum > 127) checksum -= 128; } checksum = 128 - checksum; return checksum; }

21 years, 6 months

Re: [linux-audio-dev] play'n'rec

by CK

I read: > How i can from my linux C program at the same time > take sound from souncard line input ( ,maybe change level and something else ) > AND give it back to line output system("cat /dev/dsp > /dev/dsp"); no but seriously, you might want to take a look at jack (http://jackit.sf.net/) there are example sources that come with the package to get you started. regards, x -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

21 years, 6 months

[linux-audio-dev] play'n'rec

by Ralfs Kurmis

Hi folks How i can from my linux C program at the same time take sound from souncard line input ( ,maybe change level and something else ) AND give it back to line output this program do it but with pauses ~1sec some ideas ? Tnx in advance Ralfs K #include <unistd.h> #include <fcntl.h> #include <sys/types.h> #include <sys/ioctl.h> #include <stdlib.h> #include <stdio.h> #include <linux/soundcard.h> #define LENGTH 3 /* how many seconds of speech to store */ #define RATE 8000 /* the sampling rate */ #define SIZE 8 /* sample size: 8 or 16 bits */ #define CHANNELS 1 /* 1 = mono 2 = stereo */ /* this buffer holds the digitized audio */ unsigned char buf[LENGTH*RATE*SIZE*CHANNELS/8]; int main() { int fd; /* sound device file descriptor */ int arg; /* argument for ioctl calls */ int status; /* return status of system calls */ /* open sound device */ fd = open("/dev/dsp", O_RDWR); if (fd < 0) { perror("open of /dev/dsp failed"); exit(1); } /* set sampling parameters */ arg = SIZE; /* sample size */ status = ioctl(fd, SOUND_PCM_WRITE_BITS, &arg); if (status == -1) perror("SOUND_PCM_WRITE_BITS ioctl failed"); if (arg != SIZE) perror("unable to set sample size"); arg = CHANNELS; /* mono or stereo */ status = ioctl(fd, SOUND_PCM_WRITE_CHANNELS, &arg); if (status == -1) perror("SOUND_PCM_WRITE_CHANNELS ioctl failed"); if (arg != CHANNELS) perror("unable to set number of channels"); arg = RATE; /* sampling rate */ status = ioctl(fd, SOUND_PCM_WRITE_RATE, &arg); if (status == -1) perror("SOUND_PCM_WRITE_WRITE ioctl failed"); while (1) { /* loop until Control-C */ printf("Say something:\n"); status = read(fd, buf, sizeof(buf)); /* record some sound */ if (status != sizeof(buf)) perror("read wrong number of bytes"); printf("You said:\n"); status = write(fd, buf, sizeof(buf)); /* play it back */ if (status != sizeof(buf)) perror("wrote wrong number of bytes"); /* wait for playback to complete before recording again */ status = ioctl(fd, SOUND_PCM_SYNC, 0); if (status == -1) perror("SOUND_PCM_SYNC ioctl failed"); } } --- This message contains no viruses. Guaranteed by Kaspersky Anti-Virus. www.antivirus.lv

21 years, 6 months

Re: [linux-audio-dev] System Exclusive question

by chris.wareham＠btopenworld.com

Clemens Ladisch <clemens(a)ladisch.de> wrote: > > chris.wareham(a)btopenworld.com wrote: > > Has anyone had succes in getting SysEx data flowing back and forth > > between Roland sound modules and their computer? > > Yes, SC-8820, over USB. > > > I have attached my > > simple test program in case I'm doing something obviously wrong. > > I see nothing obviously wrong. > > It might be time-saving to try the low-tech approach first: > do a "cat /dev/midi42 > somefile", then, on another console, run: > > echo -ne '\xf0\x41\x10\x16\x11\x04\x01\x76\x00\x01\x76\x0e\xf7' > /dev/midi42 > I'll try this approach tonight. > > > > However, whenever I send a Request Data > > > >message the unit doesn't appear to respond. It definitely receives the > > > >message as the MIDI activity light comes on. But when I try to read from > > > >the MIDI device file my call blocks forever. > > My unit's light is active while the dump is being transmitted (several > seconds, depending on the size of the data). Are you sure your's is > sending anything? > The MIDI activity light flashes *very* briefly, so it could be that nothing's being sent back. > > I have tried using Linux, but gave up when I couldn't get ALSA or > > OSS to recognise my USB MIDI interface, (a Yamaha UX96). Under > > NetBSD it's recognised as soon as I plug it in. > > Any somewhat recent version of ALSA does support the UX96. > I tried RedHat 9.0 and the CCRMA stuff, but I guess I mustn't have setup the modules.conf file properly. I'm used to the monolithic kernel approach, and I found the whole modules.conf thing confusing. I assume I need an entry in there to load the USB MIDI interface driver - could you send me your modules.conf so I can see what sort of entries are required? Chris

21 years, 6 months

[linux-audio-dev] Re: [MusE] More ideas :) [Track freeze] - Alsa Sequencer

by Robert Jonsson

tisdagen den 10 juni 2003 13.21 skrev Frank van de Pol: > On Tue, Jun 10, 2003 at 08:30:39AM +0200, Robert Jonsson wrote: > > Hi, > > > > > In fact the bounce feature in MusE is "realtime". It means that you > > > have to wait the real duration of the track to be rendered. > > > In a non "realtime" mode the track is rendered as fast as computer can. > > > > AFAICT the realtimeness of the bounce feature is like that because of > > design constraints. Okay, bouncing wavetracks should be possible in > > non-realtime, but not when using softsynths. > > > > This is because all softsynths use alsa-sequencer as the input interface. > > And if I'm not missing anything, this interface is strictly realtime > > based. (perhaps it can be tweaked by timestamping every note and sending > > them in batches? it seems very hard though.) > > You are right, with the current alsa-sequencer the softsynths are driven by > realtime events. Though an application can enqueue the events to the > priority queues with delivery timestamp, the scheduling is handled > internally by the alsa sequencer. This causes some problems (especially for > sample accurate synchronisation with JACK or LADSPA synth plugins (XAP?)), > but also for network transparency and support for MIDI interfaces which > accepts timing hints (Steinberg LTB or Emagic AMT ... if specs of the > protocol were available :-( ). > > During the LAD meeting at Karlsruhe we discussed this and sketched a > alsa-sequencer roadmap that focusses on transition of the alsa-sequencer > from kernel to userspace and better integration with softsynths / JACK. > A few things from this are very much related to your track bouncing / > off-line rendering thing: > > - Provide facility to delegate scheduling to the client. The implementation > would be to deliver the events directly (without queuing) with the > timestamp attached to the registered client port. This would allow the > client to get the events before the deadline (time at which the event > should be played) and use that additional time to put the events at the > right sample position. > > Note that for the softsynth to get advantage of this the application > should enqueue the events (a bit) ahead of time and pass the timestamp. > Some of the current applications (including MusE) use the alsa-sequencer > only as event router and drive it real-time. > > Since the softsynth/plugin has no notion of the acutal time (only the > media time and sample position), rendering at arbitrary speed should be > possible: bounce faster than realtime or even slower than realtime for > those complex patches. > > - JACK is real-time, and bound to the sample rate of the soundcard. Since > the audio sample rate can also be used as a clock master for the alsa > sequencer this would be a good option to ensure synchronisation. The > transport of JACK and alsa sequencer can be tied together (either one of > the two acting as master, a run-time configurable option) to provide > uniform transport and media time amongst the applications that hook into > the JACK and/or alsa sequencer framework. > > For the offline rendering no nice scheme has been worked out yet; I guess > it would be something along the lines where the application that owns the > sequencer queue has full control on the transport, moving media time at the > speed the frames are actually rendered, and the app(s) generating the > events keeping at least one sample frame ahead of time. Okay, I didn't know that this had been up on the table, how far has this work progressed, was it just the Karlsruhe meeting or has more thinking occured? (fyi I'm CC:ing LAD, it might be a more appropriate place for this discussion..). Regards, Robert

21 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 June 2003