search for: 44.1k

Hi all, I'm implementing the opus codec for a proprietary RF link (for fullband audio) and want to make sure I understand something. The link is currently running at 44.1KHz - realtime (i.e. streaming from an A/D at one side, ultimately to a D/A at the other). Rather than muck with all the infrastructure, I'm looking at how to run Opus at 44.1K. I have flexibility in the frame sizes of

> I'm looking at how to run Opus at 44.1K. I have flexibility in the > frame sizes of the unencoded audio, and packet sizes on the RF link. You should probably consider resampling. It's not that expensive and it would make things easy. But otherwise, see below. On 06/14/2013 06:23 PM, Marc Lindahl wrote: > So, I was digging through the code, and I didn't see any attempt to

Thanks for the answers Benjamin? On Jun 14, 2013, at 8:05 PMEDT, Benjamin Schwartz wrote: > I have flexibility in the frame sizes of the unencoded audio, and packet sizes on the RF link. > > This implies that you don't have a very tight latency constraint, so you can afford to run a resampler. > I assume the resample costs CPU cycles? the RX is battery powered, I'd just as

Hi Jean-Marc, On Jun 15, 2013, at 2:23 AMEDT, Jean-Marc Valin wrote: >> I'm looking at how to run Opus at 44.1K. I have flexibility in the >> frame sizes of the unencoded audio, and packet sizes on the RF link. > > You should probably consider resampling. It's not that expensive and it > would make things easy. But otherwise, see below. Yes, considering your and

On 06/15/2013 12:00 PM, Marc Lindahl wrote: >> Do not do that, ever. Everything is calibrated for 48 kHz and you >> will likely cause audible noise. > > How would it cause audible noise, I don't understand that part? > After all the frequency calculations are off by 8%, that's not too > extreme... Well, the encoder is designed to follow the ear's response and

Marc Lindahl wrote: > Of course, I'm setting up a bunch of tests to evaluate these, what I was asking was more along the lines of, > If you set up the same exact, including the sample rate, do you get the same results (e.g. same code path, calculations, etc.?) If you configure a custom mode with the standard parameters (48 kHz sampling rate and a frame size of 120, 240, 480, or 960),

Hi Jean-Marc, On Jun 15, 2013, at 12:20 PMEDT, Jean-Marc Valin wrote: > > >> So I still wonder, if you set up a custom mode, but then had all the >> settings the same as a normal mode, would the codec perform worse, or >> the same? > > You'll have to try normal vs custom modes and choose. The only thing I'm > telling you is don't run a 48 kHz

Hey guys. I think Vorbis is pretty cool, but since the current OggEnc only offers 44.1kHz, it limits what I wanted to use it for. So I've been using Lame to get 16kHz mono Vorbis files. I'm curious about whether Lame does Vorbis encoding the "right" way for non-44.1k stuff, or whether it just encodes as it would for 44.1k & changes the sample rate on the output, but I'm

John, Thanks for the reply! You mentioned output sample rates should be 44100 or 48000, should I worry about input (Mic) Sample rates as well? (Currently I was requesting the sample rate on both ends to be 16000 samplesPerSecond, for ease of passing into the codec) Also, do you recommend any particular resampler that I should use, or are any of the ones out there probably okay, or should

Hullo, folks. As the wiki is *still* down, I'm sending this to the list again. The EZAV EMP-400 is a small flash-based portable player with an OLED screen. I think it's still in development, because I can't find information on its pricing anywhere. The memory capacity isn't visible anywhere either, but the previous device from EZAV had 256 megs of memory.

Jack, tried the CVS version still getting: -> [05/Aug/2001:12:25:01] Kicking client 4 [cr7890-a.wlfdle1.on.wave.home.com] [Too many errors (client not receiving data fast enough)] [listener], connected for 0 seconds, 26010 bytes transfered. 0 clients connected Any idea what it means? Is it a mis-configuration? Sometime to do w/ LAME? I have no clue where to start -Russ On Sun, 5 Aug

I have a video conference like application that I've been working on for a while now, and a recent change is causing some odd problems, and I was wondering if anyone else had seen problems like this. The issue I'm seeing is that when using the sound card for capture, the audio will eventually get about 1-2 seconds out of synch (delayed), from the video. However, if I use USB devices

> -----Original Message----- > From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org]On > Behalf Of James Stanton > Sent: Thursday, October 04, 2007 12:53 PM > To: speex-dev@xiph.org > Subject: [Speex-dev] Audio Speed Variability > > > I have a video conference like application that I've been working on for > a while now, and a recent change is

> -> [05/Aug/2001:12:25:01] Kicking client 4 > [cr7890-a.wlfdle1.on.wave.home.com] [Too many errors (client not receiving > data fast enough)] [listener], connected for 0 seconds, 26010 bytes > transfered. 0 clients connected > > Any idea what it means? Is it a mis-configuration? Sometime to do w/ > LAME? I have no clue where to start Almost always this means that data

As if I hadn't had enough audio problems yet (Audacity won't record in 24/32 bits in spite of the MME driver being capable of such (verified with line-in plugin for Winamp) and stays in 16 bit, now I need to find software that works; a driver bug causing only 32 bit int to work for recording complicates things further), now I've also encountered a FLAC encoder file size limit. Look

hi folks. recently some of our customers complained about bad voice quality on the phone system. i looked at the logs and found a lot of these: [2012-11-03 08:26:38] NOTICE[11305] chan_dahdi.c: PRI got event: HDLC Abort (6) on D-channel of span 1 [2012-11-03 08:26:45] NOTICE[11305] chan_dahdi.c: PRI got event: HDLC Abort (6) on D-channel of span 1 [2012-11-03 08:26:54] NOTICE[11305]

I don't know about the input side; I have personally only experienced being bitten by the output resampler. But it seems like a safe assumption that yes, the input side is equally broken. Any resampling code found on the 'net should be suitable as long as it sounds good, doesn't take too much CPU, and is compatible with your product's licensing/distribution terms. There are

Op 07-02-12 19:50, Ralph Giles schreef: > Basically the audio is chopped into a blocks and each block is coded > either uncompressed, as a constant value (good for silence), or with > linear predictive coding plus a rice-coded residual. I don't know how > the encoder decides where to put the block boundaries. AFAIK, FLAC uses a fixed block length so block boundaries are just put

Hmmm, I am using Winamp for my client, will upgrade it, but it works for other shoutcast/icecast streams. There has to be something buggered up in my config somewhere. It sounds as if Ices is sending data too quickly to icecast(?), will blow it away and re-complie it and see what happens. Thanks for the help so far. yeah, essentialmix.ca is directly related to the Essential mix broadcasts off

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I was wondering if anyone had any advice on an audio library that is better suited to be paired with Celt in terms of latency. I'm working on an application that I would like to have running on both windows/Linux systems. I started by using the OpenAL library but I have run into an issue when feeding OpenAL small mono sample sizes that