[mcp6453[_2_]]

I'm trying to get input in Audition from the S/PDIF inputs on my M-Audio Delta
1010LT card. The source is a Lexicon MPX100 effects unit with an S/PDIF output.
Audio is getting into and out of the MPX100, as monitored through the analog
jacks. The S/PDIF output jack is connected to the red S/PDIF input jack on the
1010LT.

While I have read the manual multiple times, the current documentation does not
match the current driver software. (If there is updated documentation, I cannot
find it.) M-Audio wants a large sum of money for a support call.

What am I overlooking? I've been through the S/PDIF page in the M-Audio control
panel to find something checked that shouldn't be, or vice versa, but I can't
find it. Delta 1010 S/PDIF is selected as the input source in Audition in both
the [EV] mode and in multitrack. There is no audio at all, not even the nasty
digital noise when the invert selection is set incorrectly.

[david gourley[_2_]]

mcp6453 put forth the notion in...news:ioidnckwN-
:

I'm trying to get input in Audition from the S/PDIF inputs on my M-Audio
Delta
1010LT card. The source is a Lexicon MPX100 effects unit with an S/PDIF
output.
Audio is getting into and out of the MPX100, as monitored through the
analog
jacks. The S/PDIF output jack is connected to the red S/PDIF input jack
on the
1010LT.

While I have read the manual multiple times, the current documentation
does not
match the current driver software. (If there is updated documentation, I
cannot
find it.) M-Audio wants a large sum of money for a support call.

What am I overlooking? I've been through the S/PDIF page in the M-Audio
control
panel to find something checked that shouldn't be, or vice versa, but I
can't
find it. Delta 1010 S/PDIF is selected as the input source in Audition in
both
the [EV] mode and in multitrack. There is no audio at all, not even the
nasty
digital noise when the invert selection is set incorrectly.


Mike,

Do you have S/PDIF In checked under Master Clock ?

I think some problems have been noted to that effect.

david

[mcp6453[_2_]]

On 7/5/2011 1:55 PM, david gourley wrote:
mcp6453 put forth the notion in...news:ioidnckwN-
:

I'm trying to get input in Audition from the S/PDIF inputs on my M-Audio
Delta
1010LT card. The source is a Lexicon MPX100 effects unit with an S/PDIF
output.
Audio is getting into and out of the MPX100, as monitored through the
analog
jacks. The S/PDIF output jack is connected to the red S/PDIF input jack
on the
1010LT.

Do you have S/PDIF In checked under Master Clock ?

I think some problems have been noted to that effect.

Yes, I do.

[mcp6453[_2_]]

On 7/5/2011 4:07 PM, Soundhaspriority wrote:


"mcp6453" wrote in message
...
I'm trying to get input in Audition from the S/PDIF inputs on my M-Audio Delta
1010LT card. The source is a Lexicon MPX100 effects unit with an S/PDIF output.
Audio is getting into and out of the MPX100, as monitored through the analog
jacks. The S/PDIF output jack is connected to the red S/PDIF input jack on the
1010LT.

Sometimes an SP/DIF input won't lock to the input clock source. Try other
sources, perhaps a CD player.

The MPX100 has a 20-bit output, I discovered. Another project is running on that
computer at the moment, but I wonder if Audition/1010LT has to be set for
20-bit. As I recall, when I used this card with my Otari DAT player, it worked fine.

More to come.

[mcp6453[_2_]]

On 7/5/2011 5:48 PM, Soundhaspriority wrote:


"mcp6453" wrote in message
...
On 7/5/2011 4:07 PM, Soundhaspriority wrote:


"mcp6453" wrote in message
...
I'm trying to get input in Audition from the S/PDIF inputs on my M-Audio Delta
1010LT card. The source is a Lexicon MPX100 effects unit with an S/PDIF output.
Audio is getting into and out of the MPX100, as monitored through the analog
jacks. The S/PDIF output jack is connected to the red S/PDIF input jack on the
1010LT.

Sometimes an SP/DIF input won't lock to the input clock source. Try other
sources, perhaps a CD player.

The MPX100 has a 20-bit output, I discovered. Another project is running on that
computer at the moment, but I wonder if Audition/1010LT has to be set for
20-bit. As I recall, when I used this card with my Otari DAT player, it worked
fine.

More to come.

I just looked at the manual. There is no mention of a setting. This unit is old
enough, the digital input receiver could be inflexible.

The card is old, too. I need to find another S/PDIF source to determine where
the problem is. I don't have to have the inputs, but it would be nice.

[Arny Krueger[_4_]]

"mcp6453" wrote in message
...
On 7/5/2011 4:07 PM, Soundhaspriority wrote:


"mcp6453" wrote in message
...
I'm trying to get input in Audition from the S/PDIF inputs on my M-Audio
Delta
1010LT card. The source is a Lexicon MPX100 effects unit with an S/PDIF
output.
Audio is getting into and out of the MPX100, as monitored through the
analog
jacks. The S/PDIF output jack is connected to the red S/PDIF input jack
on the
1010LT.

Sometimes an SP/DIF input won't lock to the input clock source. Try other
sources, perhaps a CD player.

That would be my first shot - try some other source.

I have a 1010LT and recall no special problems getting it to run this way.

First check out your software setup by recording from an analog input - that
is supposed to be very easy.


The MPX100 has a 20-bit output, I discovered.

Then record it to a 32 bit floating file in Audition.

Another project is running on that
computer at the moment, but I wonder if Audition/1010LT has to be set for
20-bit.

There is only one kind of SP/DIF and it is in fact 24 bit. The software
usually picks up all 24 bits which means that the low order bits that end up
in the file are padding.

As I recall, when I used this card with my Otari DAT player, it worked
fine.

[Frank]

On Wed, 6 Jul 2011 09:39:33 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Arny Krueger" wrote:

There is only one kind of SP/DIF and it is in fact 24 bit.

Not to be picky, but it's S/PDIF, not SP/DIF.

The software usually picks up all 24 bits

Agreed.

which means that the low order bits that end up
in the file are padding.

Again, not to be picky, but if you're going to put 20 bits worth of
binary data into a 24-bit binary field, it's the high-order (leftmost
or most significant) bits that are padded (arbitrarily set to zeros),
not the low-order (rightmost or least significant) bits.

As an example, if we had 0 dBFS represented in 20-bits (2.5 bytes) but
stored in a 24-bit (3 byte) field, the value would be as follows.

0000 1111 1111 1111 1111 1111

If I'm incorrect on any of the above, then I've been laboring under a
misconception for a large number of years.

I happen to own a Lexicon MPX 100, but like almost all of my equipment
right now, it's in storage upstate rather than with me in Lower
Manhattan, but I seem to recall that it's a 2-channel, 20-bit, 44.1
kHz device, but with 24-bit DSP.

Regards,

--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/
[also covers AVCHD (including AVCCAM & NXCAM) and XDCAM EX].

[Neil Gould]

Frank wrote:
On Wed, 6 Jul 2011 09:39:33 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Arny Krueger" wrote:

which means that the low order bits that end up
in the file are padding.

Again, not to be picky, but if you're going to put 20 bits worth of
binary data into a 24-bit binary field, it's the high-order (leftmost
or most significant) bits that are padded (arbitrarily set to zeros),
not the low-order (rightmost or least significant) bits.

As an example, if we had 0 dBFS represented in 20-bits (2.5 bytes) but
stored in a 24-bit (3 byte) field, the value would be as follows.

0000 1111 1111 1111 1111 1111

If I'm incorrect on any of the above, then I've been laboring under a
misconception for a large number of years.

The order of the bits reqpresenting a value is dependent on hardware and the
OS. 0 dBFS being the largest number that can be represented, would typically
be represented as 1111 1111 1111 1111 1111 0000 in literature and such with
the least significant bits (LSB) appearing on the right, though it is
entirely possible that a computer or other device would use "big Endian"
encoding and process it as you've written it, above. Arny's comment that the
low-order bits are padded is correct, since they are the LSB, and doesn't
imply the encoding order.

--
best regards,

Neil

[Arny Krueger[_4_]]

"Frank" wrote in message
...
On Wed, 6 Jul 2011 09:39:33 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Arny Krueger" wrote:

There is only one kind of SP/DIF and it is in fact 24 bit.

Not to be picky, but it's S/PDIF, not SP/DIF.

The software usually picks up all 24 bits

Agreed.

which means that the low order bits that end up
in the file are padding.

Again, not to be picky, but if you're going to put 20 bits worth of
binary data into a 24-bit binary field, it's the high-order (leftmost
or most significant) bits that are padded (arbitrarily set to zeros),
not the low-order (rightmost or least significant) bits.

That's not how it is done in digital audio. The basic idea is that FS ~= FS
no matter how many bits are used. The MSBs remain essentially the same.

As an example, if we had 0 dBFS represented in 20-bits (2.5 bytes) but
stored in a 24-bit (3 byte) field, the value would be as follows.

0000 1111 1111 1111 1111 1111

Again, that is not how it is done these days and for at least 20 or more
years going back.

0 dB FS from 20 bits stored in 24 bits would be represented as

1111 1111 1111 1111 1111 xxxx

Where the contents of the 4 LSBs (xxxx) may vary. Ideally, the whole data
word would be randomized (dithered) since there has been a changing of the
quantization.

But, given other real-world considerations inherent in audio, the 24 bit
word may be padded with zeros or some other constant without serious adverse
effects.

If I'm incorrect on any of the above, then I've been laboring under a
misconception for a large number of years.

In fact a sine wave peaking at -3dB FS has a peak amplitude of -3 dB FS no
matter whether it is represented in 8, 16, 24, or 32 bits.

I happen to own a Lexicon MPX 100, but like almost all of my equipment
right now, it's in storage upstate rather than with me in Lower
Manhattan, but I seem to recall that it's a 2-channel, 20-bit, 44.1
kHz device, but with 24-bit DSP.

By standard and convention SP/DIF transfers 24 data bits per word, no matter
how low resolution the source is. Depending on the source, and in actual
common use, up to 8 of those bits are not unique, reliable information. Few
lose much sleep over this fact.

[Frank]

On Thu, 7 Jul 2011 08:16:32 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Neil Gould" wrote:

Frank wrote:
On Wed, 6 Jul 2011 09:39:33 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Arny Krueger" wrote:

which means that the low order bits that end up
in the file are padding.

Again, not to be picky, but if you're going to put 20 bits worth of
binary data into a 24-bit binary field, it's the high-order (leftmost
or most significant) bits that are padded (arbitrarily set to zeros),
not the low-order (rightmost or least significant) bits.

As an example, if we had 0 dBFS represented in 20-bits (2.5 bytes) but
stored in a 24-bit (3 byte) field, the value would be as follows.

0000 1111 1111 1111 1111 1111

If I'm incorrect on any of the above, then I've been laboring under a
misconception for a large number of years.

The order of the bits reqpresenting a value is dependent on hardware and the
OS. 0 dBFS being the largest number that can be represented, would typically
be represented as 1111 1111 1111 1111 1111 0000 in literature and such with
the least significant bits (LSB) appearing on the right, though it is
entirely possible that a computer or other device would use "big Endian"
encoding and process it as you've written it, above. Arny's comment that the
low-order bits are padded is correct, since they are the LSB, and doesn't
imply the encoding order.

I think that my confusion may stem from the fact that although a
former programmer, I've never coded an audio application.

Neil, in your 1111 1111 1111 1111 1111 0000 example above, where is
the ones position? Is it the right-most 1 or is it the left-most 1?

As to the byte-order (endianness), although no longer a programmer, I
do deal with that, at least on a superficial level, now and then, as I
have people who occasionally send me RIFF Wave (.wav) files that
contain AC-3 encoded audio data but with the wFormatTag field set to
0x0001 (LPCM) rather than 0x2000 (Dolby Digital AC-3).

Needless to say, when I play these files, I hear digital hash, so to
resolve the problem I fire up my favorite hex editor program and
change the value of the wFormatTag field from 0000 to 2000 but I enter
the two bytes as 0020 rather than as 2000 because of the reversed byte
order. After I've made the change and saved the file to disk, it now
plays correctly using the AC-3 codec.

--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/
[also covers AVCHD (including AVCCAM & NXCAM) and XDCAM EX].

[Neil Gould]

Hi Frank,

Frank wrote:
On Thu, 7 Jul 2011 08:16:32 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Neil Gould" wrote:

Frank wrote:
On Wed, 6 Jul 2011 09:39:33 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Arny Krueger" wrote:

which means that the low order bits that end up
in the file are padding.

Again, not to be picky, but if you're going to put 20 bits worth of
binary data into a 24-bit binary field, it's the high-order
(leftmost or most significant) bits that are padded (arbitrarily
set to zeros), not the low-order (rightmost or least significant)
bits.

As an example, if we had 0 dBFS represented in 20-bits (2.5 bytes)
but stored in a 24-bit (3 byte) field, the value would be as
follows.

0000 1111 1111 1111 1111 1111

If I'm incorrect on any of the above, then I've been laboring under
a misconception for a large number of years.

The order of the bits reqpresenting a value is dependent on hardware
and the OS. 0 dBFS being the largest number that can be represented,
would typically be represented as 1111 1111 1111 1111 1111 0000 in
literature and such with the least significant bits (LSB) appearing
on the right, though it is entirely possible that a computer or
other device would use "big Endian" encoding and process it as
you've written it, above. Arny's comment that the low-order bits are
padded is correct, since they are the LSB, and doesn't imply the
encoding order.

I think that my confusion may stem from the fact that although a
former programmer, I've never coded an audio application.

It's not so much about audio... the question is, where are the LSBs?

Neil, in your 1111 1111 1111 1111 1111 0000 example above, where is
the ones position? Is it the right-most 1 or is it the left-most 1?

The LSBs are on the right in my example. But, I don't think that's the issue
I was trying to address; it's the LSBs and not the byte order that matters,
and Arny's statement was correct about that. If, as you asserted, the MSBs
were padded, then that A/D could never reach 0 dBFS, right? ;-)

--
Neil

[Frank]

On Thu, 7 Jul 2011 18:55:59 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Neil Gould" wrote:

Hi Frank,

Frank wrote:
On Thu, 7 Jul 2011 08:16:32 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Neil Gould" wrote:

Frank wrote:
On Wed, 6 Jul 2011 09:39:33 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Arny Krueger" wrote:

which means that the low order bits that end up
in the file are padding.

Again, not to be picky, but if you're going to put 20 bits worth of
binary data into a 24-bit binary field, it's the high-order
(leftmost or most significant) bits that are padded (arbitrarily
set to zeros), not the low-order (rightmost or least significant)
bits.

As an example, if we had 0 dBFS represented in 20-bits (2.5 bytes)
but stored in a 24-bit (3 byte) field, the value would be as
follows.

0000 1111 1111 1111 1111 1111

If I'm incorrect on any of the above, then I've been laboring under
a misconception for a large number of years.

The order of the bits reqpresenting a value is dependent on hardware
and the OS. 0 dBFS being the largest number that can be represented,
would typically be represented as 1111 1111 1111 1111 1111 0000 in
literature and such with the least significant bits (LSB) appearing
on the right, though it is entirely possible that a computer or
other device would use "big Endian" encoding and process it as
you've written it, above. Arny's comment that the low-order bits are
padded is correct, since they are the LSB, and doesn't imply the
encoding order.

I think that my confusion may stem from the fact that although a
former programmer, I've never coded an audio application.

It's not so much about audio... the question is, where are the LSBs?

Neil, in your 1111 1111 1111 1111 1111 0000 example above, where is
the ones position? Is it the right-most 1 or is it the left-most 1?

The LSBs are on the right in my example. But, I don't think that's the issue
I was trying to address; it's the LSBs and not the byte order that matters,
and Arny's statement was correct about that. If, as you asserted, the MSBs
were padded, then that A/D could never reach 0 dBFS, right? ;-)

Well, that's why I asked where the ones position was located. To me,
and the systems on which I've worked, the LSB is the right-most bit
and the MSB is the left-most bit.

But in my experience the ones position, which tells me how to
interpret the number values, is normally the right-most bit, just as
it would be in the ordinary decimal notation that everyone uses
everyday.

As a simple example, if I was holding twelve pencils (or whatever) in
my hand, I would write that in decimal as 12 and not as 21. In binary,
I would code that as 1100 and if I were to place that value of 1100
into an eight-bit-wide field, I would do it as 0000 1100.

If I were, instead, to do it as 1100 0000 then that would be
misinterpreted as a decimal value of 192.

Anyway, I thank you for your response and having never worked on an
audio application and therefore not knowing better, I'll accept as
correct what you and Arny have said.

--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/
[also covers AVCHD (including AVCCAM & NXCAM) and XDCAM EX].

[Neil Gould]

Hi again,

Frank wrote:
On Thu, 7 Jul 2011 18:55:59 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
"Neil Gould" wrote:

The LSBs are on the right in my example. But, I don't think that's
the issue I was trying to address; it's the LSBs and not the byte
order that matters, and Arny's statement was correct about that. If,
as you asserted, the MSBs were padded, then that A/D could never
reach 0 dBFS, right? ;-)

Well, that's why I asked where the ones position was located. To me,
and the systems on which I've worked, the LSB is the right-most bit
and the MSB is the left-most bit.
[...]
As a simple example, if I was holding twelve pencils (or whatever) in
my hand, I would write that in decimal as 12 and not as 21. In binary,
I would code that as 1100 and if I were to place that value of 1100
into an eight-bit-wide field, I would do it as 0000 1100.

If I were, instead, to do it as 1100 0000 then that would be
misinterpreted as a decimal value of 192.

To relate your example to audio, you'd have to consider no pencils as -12,
and 12 pencils as 0. ;-) In other words, higher resolution doesn't
increase the value of 0 dBFS, it provides greater bit depth for the audio
signal.

--
Best regards,

Neil

[Frank]

On Wed, 06 Jul 2011 20:37:04 -0400, in 'rec.audio.pro',
in article S/PDIF Input on M-Audio Delta 1010LT,
Frank wrote:

I happen to own a Lexicon MPX 100, but like almost all of my equipment
right now, it's in storage upstate rather than with me in Lower
Manhattan, but I seem to recall that it's a 2-channel, 20-bit, 44.1
kHz device, but with 24-bit DSP.

I hate to follow-up on my own post, and not that it matters, but for
the sake of accuracy (and to help maintain what little sanity I have
left at this point in time), looking at http://images.google.com/ this
afternoon, it's quite obvious that I do *not*, as (incorrectly) stated
above, own a Lexicon MPX 100. What I actually own is the Lexicon MPX
1.

In fact, I just downloaded the MPX 1 manual from the Lexicon Web site
and browsing through it I can distinctly recognize pages where in my
hardcopy version of the manual I recall written little notes to
myself.

I think that the MPX 100 and the MPX 1 are similar in that they both
support a max sample rate of just 44.1 kHz, which may help to explain
why I never used my MPX 1 all that much since I was usually dealing
with 48 kHz audio from a camcorder.

--
Frank, Independent Consultant, New York, NY
[Please remove 'nojunkmail.' from address to reply via e-mail.]
Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/
[also covers AVCHD (including AVCCAM & NXCAM) and XDCAM EX].