Home |
Search |
Today's Posts |
#1
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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. |
#2
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
|
#3
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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. |
#4
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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. |
#5
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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. |
#6
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
"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. |
#7
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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]. |
#8
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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 |
#9
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
"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. |
#10
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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]. |
#11
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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 |
#12
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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]. |
#13
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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 |
#14
Posted to rec.audio.pro
|
|||
|
|||
S/PDIF Input on M-Audio Delta 1010LT
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]. |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Delta 1010LT channel 1/2 no input level | Pro Audio | |||
Delta 1010LT - Need help configuring for monitoring input duringrecording | Pro Audio | |||
M-audio Delta 1010LT Problem | Tech | |||
M-Audio Delta 1010LT trouble | Pro Audio | |||
Delta 1010LT audio trouble | Pro Audio |