Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

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"

22 years, 7 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

22 years, 7 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; }

22 years, 7 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)

22 years, 7 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

22 years, 8 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

22 years, 8 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

22 years, 8 months

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

by chris.wareham＠btopenworld.com

Jay Vaughan <seclorum(a)mac.com> wrote: > > >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 don't understand why you're re-inventing the wheel ... why don't > you try to write your app using one of the MIDI libs out there which > already work, such as MidiShare for example? > > I can't see any obvious glaring problems with your code, but I'd > recommend you try to write your app using an already-working MIDI > library... there's just no point re-inventing a MIDI API for Linux, > the ones that are there already work perfectly well. > Hi Jay, I took a look at MidiShare, but unfortunately it wont work on NetBSD as it depends on a kernel module. 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. I did Google around expecting there to be lots of convenient MIDI libraries, but I couldn't find any. Is ALSA that good that no one uses anything else? It seems to be overkill for System Exclusive stuff to use a high level library though, especially as the details differ on virtually every MIDI device. Chris

22 years, 8 months

[linux-audio-dev] Bom dia linux-audio-dev

by kandrak

Message to linux-audio-dev(a)music.columbia.edu Ola!!!! linux-audio-dev GANHAMOS O PRÊMIO DE MELHOR SITE DO RAMO ======Estamos operando em Novo Formato====== Confira em: escuta21.kit.net ou http://www.escuta21.kit.net ei.... linux-audio-dev Cuidado com o que fala ao Celular... ele tb tem ouvidos... para remover o linux-audio-dev(a)music.columbia.edu de nossa lista responda este e-mail e coloque remover nos perdoe o transtorno...ok? kandrak

22 years, 8 months

[linux-audio-dev] Re: [linux-audio-user] mapping alsa devices to oss devices

by Allan Klinbail

Hi I can't answer your question.. but this email has answered one of mine, and I have successfully edited my asound.conf file to be able to do what you are doing.. recording in through discrete channels and outputting though discrete channels.. Maybe someone on the ardour list can answer us both by confirming that this will allow multichannel recording on ardour (a possible solve to the question I think you are asking) cheers Allan P.S I'm still working on a way of then combining my Delta66 with my intel8x0 (built-in to MOBO) so that I can use the stereo out of the intel8x0 for monitoring while using the outputs of the Delta66 for channel recording. (i.e. sending output into the mixing desk to use outboard processing gear or for external mixdown of tracks) cheers Allan On Mon, 2003-06-09 at 20:25, Akos Maroy wrote: > In my quest to record from the different channels of the Delta 1010LT > have come so far that I can address the different hardware inputs using > ALSA device names, while using an appropriate /etc/asound.conf file. > e.g. I can > > arecord -f cd -d 5 -D channel2 test.wav > > and this would record from hardware input channel #2. I have four stereo > input channels, e.g channel1 ... channel4, plus the spdif channel. So > far, so good. > > Now I would need a way to map these channels to OSS /dev/dsp interfaces. > something like: > > /dev/dsp1 -> channel1 > /dev/dsp2 -> channel2 > /dev/dsp3 -> channel3 > /dev/dsp4 -> channel4 > > I understand that I would need to use the kernel module snd-pcm-oss to > achieve this. how can I tell this module to map to the appropriate ALSA > devices? > > BTW, the contents of this asound.conf file is: > > pcm.ice1712 { > type hw > card 0 > device 0 > } > > # adcdac 1&2 > pcm.channel1 { > type plug > ttable.0.0 1 > ttable.1.1 1 > slave.pcm ice1712 > } > > # adcdac 3&4 > pcm.channel2 { > type plug > ttable.0.2 1 > ttable.1.3 1 > slave.pcm ice1712 > } > > #adcdac 5&6 > pcm.channel3 { > type plug > ttable.0.4 1 > ttable.1.5 1 > slave.pcm ice1712 > } > > # adcdac 7&8 > pcm.channel4 { > type plug > ttable.0.6 1 > ttable.1.7 1 > slave.pcm ice1712 > } > > #SPDIF channels only > pcm.ice1712_spdif { > type plug > ttable.0.8 1 > ttable.1.9 1 > slave.pcm ice1712 > } -- Allan Klinbail <allank(a)labyrinth.net.au>

22 years, 8 months

Jump to page:

2026

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