10 Dec
2005
10 Dec
'05
5:52 p.m.
Hi,
I have a minidisc player with S/PDIF output and an ALSA supported
soundcard (details if the card are not really important for the
problem at hand).
I sample recordings via
arecord -D spdif -f cd
Ok, and here is the rub: playback is not perfect, and neither seems to
be the sampling. Probably at times error interpolation sets in,
probably at times samples get lost or replicated. Not much, perhaps
once per minute or so. This leads to audible clicks, of course.
Then there are leading and trailing zeros.
Now what I want to do is just sample the stuff three times and do a
three-way merge. Never mind clever click detecting and interpolation
schemes: just use redundancy.
I have not found a tool for that.
Anybody have a clue how to go about that? If things come to worst,
I'll have to write a merging tool.
Bonus points would be if the thing worked on-line, taking one
recording, sampling new samples and just writing the diff out. Run
this three times, then run a merge program on the first complete
sampling as well as all diffs. That would save quite a bit of disk
space.
However, it is not really mandatory: just merging three full size
files would be fine.
Anybody have an idea whether there is some suitable starting point or
utility for this kind of thing?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
10 Dec
10 Dec
6:08 p.m.
On Sat, 2005-12-10 at 22:52 +0100, David Kastrup wrote:
I have a minidisc player with S/PDIF output and an
ALSA supported
soundcard (details if the card are not really important for the
problem at hand).
I sample recordings via
arecord -D spdif -f cd
Ok, and here is the rub: playback is not perfect, and neither seems to
be the sampling. Probably at times error interpolation sets in,
probably at times samples get lost or replicated. Not much, perhaps
once per minute or so. This leads to audible clicks, of course.
Well, it would be better to figure out why arecord doesn't work than try
to work around it.
Use "arecord -v -D spdif -f cd" and see if a rate conversion plugin is
used. The ALSA SRC is not great so if that is the case then you'll get
better results sampling at 48KHz (-f dat) then downsampling to 44.1
afterward.
Lee
6:39 p.m.
Lee Revell <rlrevell(a)joe-job.com> writes:
On Sat, 2005-12-10 at 22:52 +0100, David Kastrup
wrote:
Does not appear to be the case, and anyway, there would not be a
reason that rate conversion leads to glitches. Here you are:
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Hardware PCM card 0 'C-Media PCI CMI8738-MC6' device 2 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time : 1000
tstamp_mode : NONE
period_step : 1
sleep_min : 0
avail_min : 4096
xfer_align : 4096
start_threshold : 1
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Aborted by signal Interrupt...
On another note: it would seem like a simple enough task to let the
recording start with the first non-zero sample. I have been
completely unable to make head or tails of the manual page
descriptions of the arecord options presumably intended for that and
have found absolutely no setting that would not either drop quite more
than just the initial zeros, or not drop anything at all.
I'd also like to prune trailing zeros at some point of time. arecord
does not seem to have options for doing that, I guess.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
I have a minidisc player with S/PDIF output and
an ALSA supported
soundcard (details if the card are not really important for the
problem at hand).
I sample recordings via
arecord -D spdif -f cd
Ok, and here is the rub: playback is not perfect, and neither seems to
be the sampling. Probably at times error interpolation sets in,
probably at times samples get lost or replicated. Not much, perhaps
once per minute or so. This leads to audible clicks, of course.
Well, it would be better to figure out why arecord doesn't work than try
to work around it.
Use "arecord -v -D spdif -f cd" and see if a rate conversion plugin is
used. The ALSA SRC is not great so if that is the case then you'll get
better results sampling at 48KHz (-f dat) then downsampling to 44.1
afterward.
6:53 p.m.
On Sat, 2005-12-10 at 23:39 +0100, David Kastrup wrote:
On another note: it would seem like a simple enough
task to let the
recording start with the first non-zero sample. I have been
completely unable to make head or tails of the manual page
descriptions of the arecord options presumably intended for that and
have found absolutely no setting that would not either drop quite more
than just the initial zeros, or not drop anything at all.
I'd also like to prune trailing zeros at some point of time. arecord
does not seem to have options for doing that, I guess.
Well arecord is more of a debugging tool and a demonstration of the ALSA
API than a full featured recording app. Check the list archives, I am
pretty sure this was discussed not long ago.
Lee
6:59 p.m.
Lee Revell <rlrevell(a)joe-job.com> writes:
On Sat, 2005-12-10 at 23:39 +0100, David Kastrup
wrote:
Any keywords? I skimmed the subject lines from the past few months
and don't think I hit anything obvious.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On another note: it would seem like a simple
enough task to let the
recording start with the first non-zero sample. I have been
completely unable to make head or tails of the manual page
descriptions of the arecord options presumably intended for that and
have found absolutely no setting that would not either drop quite more
than just the initial zeros, or not drop anything at all.
I'd also like to prune trailing zeros at some point of time. arecord
does not seem to have options for doing that, I guess.
Well arecord is more of a debugging tool and a demonstration of the ALSA
API than a full featured recording app. Check the list archives, I am
pretty sure this was discussed not long ago. 
11 Dec
11 Dec
10:06 a.m.
David Kastrup <dak(a)gnu.org>rg>:
arecord -D spdif -f cd
Ok, and here is the rub: playback is not perfect, and neither seems
to be the sampling. Probably at times error interpolation sets in,
probably at times samples get lost or replicated. Not much, perhaps
once per minute or so. This leads to audible clicks, of course.
You're assuming a flawed spdif stream and, well, people keep suggesting
changing the spdif cable. It's supposed to have an effect on stream
quality worth mentioning. Don't know myself.
But try setting the c-media card to respect the incoming spdif clock.
That should make a difference.
Wolfgang
6:44 p.m.
Wolfgang Woehl <tito(a)rumford.de> writes:
David Kastrup <dak(a)gnu.org>rg>:
Any idea how? I have had just a few weird experiences: without any
preparation, recording (and monitoring) is just one crackly mess. If
I do
aplay /usr/share/sounds/startup.wav
while arecord -D spdif has not yet given up with an error, (the
recording has this muted), then the recording will turn into working
pretty much transparently. However, starting a new recording session
will revert to snack, crackle and pop.
If I do
aplay -D spdif /usr/share/sounds/startup.wav
however, a subsequent arecord -D spdif command will not revert to
crackle mode.
So there is already something going on which I don't understand. In
"crackle mode", there is basically just noise, but the noise level is
correlated with the amplitude of the sound source.
So what would one actually have to do to have the "incoming spdif
clock" respected?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
arecord -D spdif -f cd
Ok, and here is the rub: playback is not perfect, and neither seems
to be the sampling. Probably at times error interpolation sets in,
probably at times samples get lost or replicated. Not much, perhaps
once per minute or so. This leads to audible clicks, of course.
You're assuming a flawed spdif stream and, well, people keep suggesting
changing the spdif cable. It's supposed to have an effect on stream
quality worth mentioning. Don't know myself.
But try setting the c-media card to respect the incoming spdif clock.
That should make a difference.
8:50 p.m.
David Kastrup <dak(a)gnu.org>rg>:
So what would one actually have to do to have the
"incoming spdif
clock" respected?
The linux settings tool for my HDSP has "Preferred Sync Reference" that
lets me choose between internal wordclock, ADAT and SPDIF in's. Your
card should have that too. I'd check ALSA docs or the manual.
Wolfgang
14 Dec
14 Dec
2:24 p.m.
On Sun, Dec 11, 2005 at 11:44:32PM +0100, David Kastrup wrote:
>> Ok, and here is the rub: playback is not
perfect, and neither seems
>> to be the sampling. Probably at times error interpolation sets in,
>> probably at times samples get lost or replicated. Not much, perhaps
>> once per minute or so. This leads to audible clicks, of course.
xruns? do you still get the clicks when the card is in loop-back mode?
(this will completely bypass the OS and all driver or xrun issues)
So there is already something going on which I
don't understand. In
"crackle mode", there is basically just noise, but the noise level is
correlated with the amplitude of the sound source.
This sounds like you might possibly be a victim of a known
bug on this hardware. Try changing the "IEC958 In Phase Inverse" switch.
So what would one actually have to do to have the
"incoming spdif
clock" respected?
There is nothing to set on this card. It automatically syncs to
the incoming spdif when this input is selected.
cheers
--
Tim Orford
3:01 p.m.
Tim Orford <tim(a)pluginz.com> writes:
Of course, I tried that. IIRC it might possibly changes the overall
sound of the noise, but does not change it from being noise. And once
the card is in working mode, I don't think it makes a difference.
Ok, thanks.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
On Sun, Dec 11, 2005 at 11:44:32PM +0100, David
Kastrup wrote:
None.
>> Ok, and here is the rub: playback is not
perfect, and neither seems
>> to be the sampling. Probably at times error interpolation sets in,
>> probably at times samples get lost or replicated. Not much, perhaps
>> once per minute or so. This leads to audible clicks, of course.
xruns? do you still get the clicks when the card is in
loop-back mode?
I think, occasionally. This can also partly (though not completely)
be a problem of the signal source. Whatever the source of the
problem, it would be easy enough to rectify it using multiple passes.
So there is
already something going on which I don't understand. In
"crackle mode", there is basically just noise, but the noise level is
correlated with the amplitude of the sound source.
This sounds like you might possibly be a victim of a known bug on
this hardware. Try changing the "IEC958 In Phase Inverse" switch. So what would
one actually have to do to have the "incoming spdif
clock" respected?
There is nothing to set on this card. It automatically syncs to the
incoming spdif when this input is selected.
6916
days inactive
6920
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
4 participants
participants (4)
-
David Kastrup -
Lee Revell -
Tim Orford -
Wolfgang Woehl