;t see anything specifically in the changelogs since 1.0.25 that
addressed this concern but I very well could have misinterpreted what I was
reading.
Thoughts?
- Paul Braman
--
___
Al
ck for
embedded compressed audio. That's the next on my list.
So, detecting hot-plugged sample rates?
- Paul Braman
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based appli
serve as a
pretty good reference if someone else has the same kind of question in
the future.
Paul Braman
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat l
rson that deals
with concise examples I haven't figured out the answers yet.
Paul Braman
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landsca
y particular
application.
It seems like, sometimes, the stuff that is trying to make things
simple just makes it more complicated to deal with in the end. Bleh.
Paul Braman
--
Nokia and AT&T present the 2010 Calling
re out how to read the raw
S/PDIF data accurately and record it to storage. Once in storage I can
deconstruct the S/PDIF stream using tools you've mentioned before in
this thread.
Tons of fun learning, but it sure is a steep curve.
Paul Braman
--
rmat
set channels
set rate
... but then fail to properly talk about the vital "set buffer/period"
is a generic enough sense to make a good beginners document than makes
sense. (Hence, my other thread.)
When this thread is finished, I
and giving me
aligned blocks. Is this an assumption I can make?
Some pointers on where to start learning about all of this would be
great. After reading lots of documents I could currently find and
trying to read code in existing programs I don't see anything
of
"set to maximum buffer and divide into four periods" or "buffer about
a second and divide into about 8 periods." It all just tastes too
wishy-washy for me. But, I'm only one person.
Paul Braman
---
Paul Braman wrote:
>
> I guess therein lies some of the fundamental difference with how I was
> previously thinking. I figured I could just ask the driver/device for
> some basic defaults that should work but, instead, I should *tell* it
> what basic defaults I can live with. (Set b
) will give me a
general buffer size for me to use. I'm going to try this stuff out on
our production hardware (all kinds of different devices and drivers)
and see how it behaves. As long as there are no xruns we should be
go
as I can tell. So, since all I want to do is capture audio from
any soundcard I choose and record it to a file (I don't care much
about perfect latency behavior) what the heck should a generic ALSA
capture program do?
Paul Braman
--
e
around that sets buffer times and periods and all that crap and if
that is what I must do, what are the basic settings that will apply to
any hardware I'm working with? (Onboard audio card, PCI tuner card,
USB sound card, etc.)
Once I figure this out I need to move on to S/PDIF r
13 matches
Mail list logo
