On Friday 13 June 2008, Grant wrote:
> pcm.my_device
Sorry, thought it would be understood that 'my_device' is the alsa alias
(in my case the the name of the kernel module without the
leading "snd-") for the hardware device in question (see your
modules.conf file or whatever is proper for your
>> I'm trying to get music from mpd to my USB DAC in 100% untouched
>> form. My mpd.conf is as follows:
>>
>> audio_output {
>> type "alsa"
>> name "USB Monica"
>> device "hw:0,0"
>> format "44100:16:2"
>> }
>
> Don't know anything about mpd but you can set up an asoundrc "plug" in
> alsa that will
Hi all,
I'm running debian etch with 2.6.18-6-686 kernel.
I have a asus p5kc mother board
lspci give:
00:1b.0 Audio device: Intel Corporation Unknown device 293e (rev 02)
Subsystem: ASUSTeK Computer Inc. Unknown device 829f
Flags: bus master, fast devsel, latency 0, IRQ 15
On Thu, Jun 12, 2008 at 7:00 PM, Roman Haefeli <[EMAIL PROTECTED]> wrote:
> hi mark
>
> thanks a lot for the detailed eplanation.
>
> On Thu, 2008-06-12 at 18:45 -0700, Mark Knecht wrote:
>
>>
>> Technically, I think you're looking for a Jack aware resampling
>> plugin. you would send your 44.1K so
hi mark
thanks a lot for the detailed eplanation.
On Thu, 2008-06-12 at 18:45 -0700, Mark Knecht wrote:
>
> Technically, I think you're looking for a Jack aware resampling
> plugin. you would send your 44.1K sound file to that device and then
> let it resample it to the Jack sample rate - 48K
On Thu, Jun 12, 2008 at 6:05 PM, Roman Haefeli <[EMAIL PROTECTED]> wrote:
>
> are you saying, that it is simply not possible to run jackd over an alsa
> plugin, that does resampling or mixing? if so, does that mean, that
Yes, I am saying that. Jack communicates directly with the hardware.
Jack ge
On Thu, 2008-06-12 at 17:24 -0700, Mark Knecht wrote:
> On Thu, Jun 12, 2008 at 4:30 PM, Roman Haefeli <[EMAIL PROTECTED]> wrote:
> > actually, my problem is not jackd related at all. i cannot use a
> > samplerate other than 48k with any application i tried, not only with
> > jackd. isn't alsa supp
On Thu, Jun 12, 2008 at 4:30 PM, Roman Haefeli <[EMAIL PROTECTED]> wrote:
> actually, my problem is not jackd related at all. i cannot use a
> samplerate other than 48k with any application i tried, not only with
> jackd. isn't alsa supposed to provide resampling, if necessary?
>
> i forgot to ment
actually, my problem is not jackd related at all. i cannot use a
samplerate other than 48k with any application i tried, not only with
jackd. isn't alsa supposed to provide resampling, if necessary?
i forgot to mention the hardware:
Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audi
On Thursday 12 June 2008, Florian Faber wrote:
> So, please tell me - how should a 'pro audio chain' look like?
I'm not saying one should never work with floats - I'm sure there's a
very good reason for it, but the chain should still be able to
support "digital wire" capability if desired. You m
hi all
i am not quite sure, if this is the right place to ask, but from what i
heard, alsa is capable of doing resampling, when needed (e.g when
playing a 44.1 file on a card, that natively only runs at 48k).
however, i seem not to be able to use those capabilites, when running
jackd. no matter w
Chris,
> > On IEEE 32 bit floats the mantissa is 23 bit, so there might be
> > situations where you loose the LSB.
> And that was the only point - a "pro audio chain" should be able to
> support "digital wire" capability.
This has nothing to do with the original poster's issues, so I changed
the
On Thursday 12 June 2008, Florian Faber wrote:
> On IEEE 32 bit floats the mantissa is 23 bit, so there might be
> situations where you loose the LSB.
And that was the only point - a "pro audio chain" should be able to
support "digital wire" capability.
> And as long as it doesn't support the sa
On Thursday 12 June 2008 20:10:04 Chris Smith wrote:
> On Thursday 12 June 2008, Florian Faber wrote:
> > What makes you think converting a 16 bit unsigned integer to a IEEE
> > 32 bit float and back would change the value?
> Should have used a 24 bit example. I'm of the opinion that with it
> the
On Thu, 2008-06-12 at 14:10 -0400, Chris Smith wrote:
> On Thursday 12 June 2008, Florian Faber wrote:
> > What makes you think converting a 16 bit unsigned integer to a IEEE
> > 32 bit float and back would change the value?
>
> Should have used a 24 bit example. I'm of the opinion that with it th
Hello,
I've been receiving some Australian help on getting flite working on the
H2210 ipaq. (thanks for that!)
But it's not 100% yet on the ipaq:
It appears that mono audio goes to the null device.
Stereo audio goes to the default device.
flite generates mono audio.
When I use the mono to stereo
On Thursday 12 June 2008, Florian Faber wrote:
> What makes you think converting a 16 bit unsigned integer to a IEEE
> 32 bit float and back would change the value?
Should have used a 24 bit example. I'm of the opinion that with it the
process is not always a bit perfect translation. But I'm open
On Thursday 12 June 2008, Grant wrote:
> I'm trying to get music from mpd to my USB DAC in 100% untouched
> form. My mpd.conf is as follows:
>
> audio_output {
> type "alsa"
> name "USB Monica"
> device "hw:0,0"
> format "44100:16:2"
> }
Don't know anything about mpd but you can set up an asoundrc
Chris,
> A little peeve with some so called "pro" audio servers is their
> inability to act as a 'digital wire', ie: what goes in comes out,
> totally unchanged. As an example, there are times you may want the
> same exact 16 bits you send out of app to arrive at the audio device
> unmolested. Jac
On Monday 09 June 2008, Bill Unruh wrote:
> That will at most give you digitization noise which at 16 bit is 96dB
> below full signal. Ie, it is much less than the tape hiss from a tape
> recorder for example.
Not that tape hiss should be a standard we compare everything to :)
A little peeve with
Hola Jochen and all,
> yes, of course it is a trade-off between xruns and delay, but i do
> that adaptively as well - start with a quite low framing, measure the
> drop-out rate and reopen the soundcard in case of too much drop-outs.
> this only impacts the quality of the start-up phase and
> dmix *is* an application, conceptually it is not different to esd, artsd
> or pulseaudio opening the ALSA hardware directly. It just happens to be
> an ALSA plugin and is a part of the signal chain that ALSA-lib sets up
> by default.
>
> You can either:
>
> a) configure dmix using a custom .asou
On 12-06-08 17:09, Rene Herman wrote:
> On 12-06-08 16:14, Florian Winter wrote:
>
>> I have some more questions:
>> Is there a way to find out which soundcards support hardware mixing (and
>> have support for it implemented in their corresponding ALSA drivers)?
>
> Not all that easily from the
On 12-06-08 16:14, Florian Winter wrote:
> I have some more questions:
> Is there a way to find out which soundcards support hardware mixing (and
> have support for it implemented in their corresponding ALSA drivers)?
Not all that easily from the code. The ALSA soundcard matrix at:
http://www.a
Again thanks you for your answer. You have been of great help. Using
"plughw" instead of "default" seems to do the trick.
I have some more questions:
Is there a way to find out which soundcards support hardware mixing (and
have support for it implemented in their corresponding ALSA drivers)? Is
Florian Winter wrote:
> - What is the dmix plugin and what are the benefits of using it?
> - Is it possible to disable the dmix plugin?
> - What consequences does disabling the dmix plugin have? What essential
> features of ALSA will be missing without it?
The dmix plugin allows multiple applic
26 matches
Mail list logo
