Linux-audio-user

linux-audio-user@lists.linuxaudio.org

3 participants
20662 discussions

Re: [linux-audio-user] Converting sample rate: failed...

by davidrclark＠earthlink.net

Mikhail, I have not published my FFT-overlap resampler, but would be happy to provide it to anyone who wanted to try it. HOWEVER, it is very crude as far as the user input goes. It is command-line based and has a strange syntax. It requires installation of additional libs of my own which you may not be able to compile. I think it would be better to stick with sndfile-resample or to obtain some better FFT-overlap code (one that has an acceptable GUI). However, if you're still interested, please contact me by email separately from the list. Best regards, Dave.

21 years, 1 month

[linux-audio-user] pd & midi

by juto aviten

Hello friends, I tried to test some MIDI with PD-0.37-4 but I have few problems maybe some of you experienced? I use a mandrake 10 with kernel 2.6-sds37 and also come back on the other 2.4mm29 I had good experiences with PD-036 & MIDI but I didn't try since! jackd recognize the midiman 2x2 + controler (I tested some others apps) but it seems pd didn't write midi in jack, maybe you already no that? but even in oss there's no MIDI, there is no read/write permissions on /dev/midi even if we write on it -mididev 1 2 3, others application work fine! if someone have an idea, please answer!! thanks juto

21 years, 1 month

[linux-audio-user] Converting sample rate: failed...

by davidrclark＠earthlink.net

Mikhail, I downloaded the original and c0 versions of your WAV files. I could hear only very little difference between these files, and it took many, many repeated plays to hear any difference at all. I heard nothing of the sort you mentioned (ringing and "very distorted"). I am using a sound card that runs at 48,000 samples/sec and 44,100 samples/sec, and I verified that the clock was actually switching. (It also does 96,000 --- ICE 1712 type chipset). I also used my own resampler (FFT overlap type) and heard no difference between the original and that one. So all three sounded almost identical to me, but not quite. There was a teensy-weensy difference with the sinc- based one, but it actually sounded a teensy-weensy bit better, not worse! I also listened with speakers and two different style headphones, including one studio monitor type. I agree with Erik that this ringing and distortion must come from your sound card or driver setup and additional sample-rate conversions or something like that, not from the sinc-based resampling. I am not a big fan of sinc-based resampling for fixed-rate conversions, so I would tell you if there was anything bad. I don't hear anything unacceptable at all --- other than that the source is very noisy! That's going to be hard to clean without noticeable artifacts based on some cleaning I've done in the past (Windows-based, not Linux). So I wish you good luck. Best regards, Dave.

21 years, 1 month

[linux-audio-user] Playback of 44k1 on 48k (alsa bug?)

by Mikhail Ramendik

Hello, My thanks and apologies to all who have checked my sample files, and NOT found the difference I claimed. The false alarm was caused by playback problems. So, I'd like to know if there's anything I can do about them. So here is the problem description. I am using the Intel ICH5 AC97 codec, on a rather good Asus motherboard. I connect an A/V receiver to the SPDIF output. I am using the 2.6.8.1 kernel. I have applied the -ck7 patch, but I don't think it affects ALSA. When I play back files that are recorded at 44k1, the sound is seriously distorted, with a "ringing" effect. This applies to all files, including MP3s I got off the Net, and to digital playback of CDs. Digital CD playback was OK on previous kernels (I think I tested 2.6.5 or 2.6.6). So this seems like an ALSA bug. Question 1. Does a known fix exist for this big? Question 2. If not, do I need to report it somehow? Yours, Mikhail Ramendik

21 years, 1 month

[linux-audio-user] M-Audio Delta 1010 - Netgear Ethernet Card incompatibility

by steve d

Just for information and the archives. There seems to be an incompatibility between the M-Audio Delta 1010 PCI card and a Netgear PCI Ethernet card. I use the Netgear ethernet card for a DSL Internet connection. Several days ago I received the Delta 1010 breakout-box/PCI-card audio card. When I installed it into an empty PCI slot and turned the computer on, it hung even before a user can access the BIOS. All the LEDs on the computer case were on (power, hard disk activity, DVD+RW drive activity) but the computer wouldn't boot or even get to the point where I could drop into BIOS. After dozens of troubleshooting configurations, including moving PCI cards around to different slots (a Soundblaster card, a US Robotics 5610B modem card, the Netgear ethernet card and the Delta-1010 card), taking all the cards out, putting the cards back in one at a time, 2 at a time, etc., I discovered that the boot-up hang was caused by the Delta 1010 and the Netgear ethernet cards, regardless of which slots they were placed in and regardless of experimenting with BIOS settings when I could get the computer to boot (when the ethernet and Delta cards were not both in the machine at the same time). The motherboard is a Tyan Tiger MPX S2466N-4M dual-AMD-Athlon-CPU board and has an onboard ethernet port I never used (because I already had the netgear ethernet card and was lazy), so the solution in my case was to permanently remove the Netgear ethernet card from the PCI slots and jumper the motherboard to use its own ethernet port, then configure FreeBSD and Debian Linux to use that ethernet port. But the mystery remains. Why does an M-Audio Delta 1010 PCI card conflict, at such a low level, with a Netgear Ethernet card? Does it only happen with Netgear cards? Does it only happen with a Tyan S2466 motherboard? Anyway, I wrote this just to share the information and for the archives. Best wishes, -steve d NM US -- ---------------------------------------------------------------- It is true that liberty is precious--so precious that it must be rationed. -Vladimir I. Lenin ----------------------------------------------------------------

21 years, 2 months

[linux-audio-user] Re: hard disk solved, but...

by Andrew Burgess

>But I continue with xruns runing jackd. >I saw something about patches for kernel 2.6.8. >I downloaded source kernel 2.6.8 and now I'll compile it. >But I don't have any idea about real necessarily of this patches and I >don't know where can I get that patches. >Somebody can help me? No offense but for your level of experience I would suggest installing Fedora Core 1 and Planet CCRMA and a 2.4 kernel. Works out of the box :-)

21 years, 2 months

[linux-audio-user] Re: Linux DAW FX box how to for noobs...New Link...

by Andrew Burgess

>On Mon, Sep 13, 2004 at 01:26:27 -0400, Eric Dantan Rzewnicki wrote: >> On this note, I have 25Mhz 486 w/12MB of RAM that has served as my >> firewall/router for 4.5 years. It's soon to be replaced by a shinier, >> newer, faster classic pentium 200MHz w/64MB of RAM. Last night I was >> thinking of how to keep it useful. I came up with the idea of writing >> some script that generates some kind of audio in realtime continuously >> to be streamed over the net. I'm thinking of trying to get it to boot >> over the network from an image on my file server and run in ram ... or >> maybe an NFS or other share. >> >> This should probably go in another thread, but does anyone know what to >> shoot for? How much realtime dsp can a box like this reasonably handle? >> Could it run hermes from a python ECI script with ecasound controllers >> controlling the parameters? >If its a 486 SX it wont have a floating pint unit, so most modern DSP >software is not an option. Good point. There is some fixed point dsp code floating around. I've heard of a fixed point only version of mad (mp3 decoder) (or is it integer only on all platforms?) and I'll bet the embedded guys have fixed point fft etc. So it would take some work...

21 years, 2 months

[linux-audio-user] xruns in jackd & not all devices in /dev/snd

by Michael Wagner

Hello everyone I recently decided to try to do some audiowork on GNU/Linux, because I'm very interestend in music and I saw that there seem to be a few nice applications for my OS of choice :-) So, I'm quite new to this stuff... Now I've got a few problems running jack. The first (minor) problem is, that at the time the rc-script for jack runs, there are no pcmC0D(0|1)(c|p) devices in /dev/snd, so jack doesn't start automatically, because it can't find them. The funny thing is, the jackd is the last daemon started. Right after the rc-script runs, the login prompt appears and after I log in, the devices exist and I can start the daemon. Does anyone have an idea about what may be the cause of this "delay" in the creation of these devices? May it have to do with me using Udev instead of DevFS? The major problem I have is, that when I start jack, I get xruns, even without any other application running... (except system processes such as crond...) They're starting to appear about 5 seconds after jack started and I'm getting one about every second. The command I use for running jackd is: jackd -d alsa -d hw:0 -n 8 (If I don't specify -n 8, jack wouldn't even start) I'm using ArchLinux, running a 'selfmade' kernel 2.6.8.1 with the voluntary preempt patch applied. Actually I wanted to keep a 2.4-kernel, but the distribution recently updatet to gcc-3.4, so I needed to patch the kernel, because without this gcc-3.4-fix it wouldn't compile anymore. Unfortunately this fix seemded to interfere with the other patches I wanted to apply for low-latency. And finally the hardware I use: - soundcard: RME DIGI 96/8 PST - CPU: AMD Athlon XP 1800 - Mainboard: some Epox E8K9A7I with VIA KT400A chipset. Does anybody have an idea on how to solve this xrun-issue? Or do you think it's impossible to do this with my hardware and linux-2.6*? Thank you in advance -Michael Wagner

21 years, 2 months

[linux-audio-user] [bogiebogart@earthlink.net: [ma-linux] Political action: Save Copyright From Hollywood]

by Eric Dantan Rzewnicki

----- Forwarded message from Tim Bogart <bogiebogart(a)earthlink.net> ----- Date: Sun, 12 Sep 2004 11:12:54 +0000 From: Tim Bogart <bogiebogart(a)earthlink.net> Subject: [ma-linux] Political action: Save Copyright From Hollywood To: Ma linux <ma-linux(a)tux.org> All, This seems to be a good item for all of us to be aware of. It's not exactly fair use, but close. It has to do with manufacturers of technologies and how the users use those technologies. Please read. Tim. ----------------- An item you can pass around among your contacts. Visit www.savebetamax.org. Congress is considering a new law, known as the INDUCE Act, which would radically change the standards of copyright. A national call-in day is being organized for this coming Tuesday to fight this. At present, a technology company which produces content copying tools is protected from liability for what its users do with the tools. The only requirement is that the tool is capable of a substantial non-infringing use. Not that the users actually use it that way, but just that the tool has the potential. This standard comes from the Supreme Court "Betamax" decision, when Hollywood tried to kill the first VCRs. The new proposal would change the standard, to one based on how the users actually do use the tool. While this seems reasonable on the surface, it's a huge change for a potential defendant. It is easy, and consequently cheap, to show that a tool could be used for a non-infringing purpose. It is much harder to gather evidence about how a tool is actually used in the real world. The result is that under present law, a technology producer is virtually immune from the threat of Hollywood action. That's why we have things like iPOD, CD-RW and DVD-R, and USB thumb drives. Under the new standard, Hollywood could cripple any new technology that doesn't have the money to stand up to a multi-megabuck legal assault. Spread the word, and get people to call their congress-critters. It's important. -- David Hayes david(a)hayes-family.org _______________________________________________ ma-linux mailing list ma-linux(a)tux.org http://www.tux.org/mailman/listinfo/ma-linux ----- End forwarded message -----

21 years, 2 months

Re: [linux-audio-user] realtime-lsm in the kernel

by David Baron

On Thursday 09 September 2004 19:00, linux-audio-user-request(a)music.columbia.edu wrote: > Go for it. i would definetly like to save the extra step of compiling > the realtime lsm each time i upgrade my kernel.. And i think it might > prove useful even for non audio users.. Often security stuff likes to > mlock small portions of memory, too, etc.. Yes, except that the realtime-lsm precompiled binary is not updated on Sid each time the kernel is. The only way to keep it current is to compile it yourself. Compiles quickly and reliably--just remember to copy the .ko to the correct place and then reboot.

21 years, 2 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-user