Jerry Avins wrote:> Richard Owlett wrote: > > ... > >> When reading posts to comp.speech.users about using SR in real world, >> I have "gut feel" that SR as a system is not properly factored. >> *EVERYTHING* is dumped on the main CPU. > > > Why not? It's cheaper that way.Yes, maybe. Historically that would have been true and the proper trade off. Now I think it leads actually to a increase in cost for a relative performance level. Similar to software bloat -- Why be efficient with all those MB and MIPS.> One of my early radio designs passed the > signal through the same tube three times: once at RF, again at IF, and a > third time at audio. I resented needing a separate tube for the local > oscillator, but at least it also contained the diode for the detector. > >> As there is so much discussion of appropriate acoustic environment and >> microphone used. I would apportion independent processors to: >> 1. filter that optimized speaker's formants >> 1.a. optimistically do some sort of "shifting" [pitch and ???] to a >> "standard" >> 2. filter to de-emphasize local interference >> 3. phoneme recognition >> 4. AI-like section that chooses between "to","too","two" etc. > > > Some people have one car to impress clients, another to take to the > market, and yet another for vacations. (You need only one roof on a > three-story house.) > >> Have I displayed enough ignorance to show why I'm not quite ready to >> implement any hardware solution? > > > Nah. Try harder. :-) > >> I also have a problem with SR industry/marketplace. They are >> interested in "continuous recognition". I want "command and >> control"/"discrete recognition". Several VAR's have been patient >> enough to explain the problem. > > > I don't even know what you're writing about. > >> Having ~4 years till retirement, I should be able to become somewhat >> educated in DSP and SR. > >
How to start-off??
Started by ●November 2, 2005
Reply by ●November 7, 20052005-11-07
Reply by ●November 7, 20052005-11-07
Richard Owlett wrote:> Jerry Avins wrote: > >> Richard Owlett wrote: >> >> ... >> >>> When reading posts to comp.speech.users about using SR in real world, >>> I have "gut feel" that SR as a system is not properly factored. >>> *EVERYTHING* is dumped on the main CPU. >> >> >> >> Why not? It's cheaper that way. > > > Yes, maybe. Historically that would have been true and the proper trade > off. Now I think it leads actually to a increase in cost for a relative > performance level. Similar to software bloat -- Why be efficient with > all those MB and MIPS.In my kitchen, there is a drawer for flatware that I also keep some utensils (serving pieces, ice pick ...) in. I could have instead smaller drawers side by side for tablespoons, teaspoons, forks, knives, and miscellaneous. The collection might even fit into the same space, but it would certainly require more drawer slides and for the most part, it would be less convenient to use. You are right to want to compartmentalize the various tasks that your SR (whatever that is) machine needs to do. The sensible way to accomplish that when item cost matters is through software modules including interrupt routines. In a one-off construction, design time outweighs parts cost, so stringing boxes together is a good way do do the job. Be aware, though, that the finished gizmo will be bigger and less reliable that the commercial approach. ... Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●November 7, 20052005-11-07
"Jerry Avins" <jya@ieee.org> wrote in message news:BOKdnZZ3a-wK6fLeRVn-hA@rcn.net...> Richard Owlett wrote: >> Jerry Avins wrote: >> >>> Richard Owlett wrote: >>> >>> ... >>> >>>> When reading posts to comp.speech.users about using SR in real world, I >>>> have "gut feel" that SR as a system is not properly factored. *EVERYTHING* >>>> is dumped on the main CPU. >>> >>> >>> >>> Why not? It's cheaper that way. >> >> >> Yes, maybe. Historically that would have been true and the proper trade off. >> Now I think it leads actually to a increase in cost for a relative >> performance level. Similar to software bloat -- Why be efficient with all >> those MB and MIPS. > > In my kitchen, there is a drawer for flatware that I also keep some utensils > (serving pieces, ice pick ...) in. I could have instead smaller drawers side > by side for tablespoons, teaspoons, forks, knives, and miscellaneous. The > collection might even fit into the same space, but it would certainly require > more drawer slides and for the most part, it would be less convenient to use. > > You are right to want to compartmentalize the various tasks that your SR > (whatever that is) machine needs to do. The sensible way to accomplish that > when item cost matters is through software modules including interrupt > routines. In a one-off construction, design time outweighs parts cost, so > stringing boxes together is a good way do do the job. Be aware, though, that > the finished gizmo will be bigger and less reliable that the commercial > approach.SR = speech recognition. The issue of using the main CPU vs. dedicated add-on hardware seems to always be with us in various forms, even as CPU speed increases greatly, etc. The trade-offs are pretty obvious, some of the main ones being: the dedicated hardware gives you predictable guaranteed operation, immunity from OS issues and "bugs" whereas using the main CPU requires no extra cost/installation complexity, opening the product to a much larger audience. In terms of just raw processing, at any given point in time, you can probably come up with a better solution with add-on hardware (DSP cards, etc.), but in a few years main CPUs will catch up and be able to provide similar performance. I have an audio recording system on an ISA card that was designed in the early nineties. It uses its own CPU and DSPs and directly-attached SCSI disks to do recording, editing, processing, etc. relying on the PC only for power and high-level control. At the time, it blew the doors off any solution that used the CPU only. Now however, over a decade later, its performance is dismal compared to what could be done on a ~$500 PC. But you can still buy other dedicated hardware recording systems that out-perform desktop PCs.
Reply by ●November 8, 20052005-11-08
Jon Harris wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:BOKdnZZ3a-wK6fLeRVn-hA@rcn.net... > >>Richard Owlett wrote: >> >>>Jerry Avins wrote: >>> >>> >>>>Richard Owlett wrote: >>>> >>>> ... >>>> >>>> >>>>>When reading posts to comp.speech.users about using SR in real world, I >>>>>have "gut feel" that SR as a system is not properly factored. *EVERYTHING* >>>>>is dumped on the main CPU. >>>> >>>> >>>> >>>>Why not? It's cheaper that way. >>> >>> >>>Yes, maybe. Historically that would have been true and the proper trade off. >>>Now I think it leads actually to a increase in cost for a relative >>>performance level. Similar to software bloat -- Why be efficient with all >>>those MB and MIPS. >> >>In my kitchen, there is a drawer for flatware that I also keep some utensils >>(serving pieces, ice pick ...) in. I could have instead smaller drawers side >>by side for tablespoons, teaspoons, forks, knives, and miscellaneous. The >>collection might even fit into the same space, but it would certainly require >>more drawer slides and for the most part, it would be less convenient to use. >> >>You are right to want to compartmentalize the various tasks that your SR >>(whatever that is) machine needs to do. The sensible way to accomplish that >>when item cost matters is through software modules including interrupt >>routines. In a one-off construction, design time outweighs parts cost, so >>stringing boxes together is a good way do do the job. Be aware, though, that >>the finished gizmo will be bigger and less reliable that the commercial >>approach. > > > SR = speech recognition. > > The issue of using the main CPU vs. dedicated add-on hardware seems to always be > with us in various forms, even as CPU speed increases greatly, etc. The > trade-offs are pretty obvious, some of the main ones being: the dedicated > hardware gives you predictable guaranteed operation, immunity from OS issues and > "bugs" whereas using the main CPU requires no extra cost/installation > complexity, opening the product to a much larger audience. In terms of just raw > processing, at any given point in time, you can probably come up with a better > solution with add-on hardware (DSP cards, etc.), but in a few years main CPUs > will catch up and be able to provide similar performance. > > I have an audio recording system on an ISA card that was designed in the early > nineties. It uses its own CPU and DSPs and directly-attached SCSI disks to do > recording, editing, processing, etc. relying on the PC only for power and > high-level control. At the time, it blew the doors off any solution that used > the CPU only. Now however, over a decade later, its performance is dismal > compared to what could be done on a ~$500 PC. But you can still buy other > dedicated hardware recording systems that out-perform desktop PCs. > >Thank you, I'm not "all wet", just "slightly damp" ;) For context, I said "Have I displayed enough ignorance to show why I'm not quite ready to implement any hardware solution?" To which Jerry replied "Nah. Try harder. :-)" I think Jon has identified a key point. Those of my and Jerry's vintage would identify with argument between component HIFI and 'other' ;/ More seriously I have 'gut feel' that "signal conditioning" might be best done externally to a "one size fits all" speech recognition program. I read reports on comp.speech.users of the importance of choosing just the right mike and having an "ideal" acoustic environment. I do not doubt these assertions are true. *THEY _SHOULD NOT_ BE TRUE* !!!!!!!!!!!!!!!!!!!!!!!! Gee, why do people say I tilt at windmills ;?
Reply by ●November 9, 20052005-11-09
Richard Owlett wrote: ...> More seriously I have 'gut feel' that "signal conditioning" might be > best done externally to a "one size fits all" speech recognition program.While that's absolutely correct, the reasons for using separate processors to accomplish those functions don't apply if you write all your own code. COTS reduces software cost, often at the expense of added hardware.> I read reports on comp.speech.users of the importance of choosing just > the right mike and having an "ideal" acoustic environment. > > I do not doubt these assertions are true. > *THEY _SHOULD NOT_ BE TRUE* !!!!!!!!!!!!!!!!!!!!!!!!I agree about "just the right mic", but it must be true that quieter and less reflective backgrounds are better.> Gee, why do people say I tilt at windmills ;?You have to do a thing yourself if you want it done right. Some things are not worth doing yourself. Tilting at windmills is wanting those things to be right anyway. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●November 9, 20052005-11-09
Jerry Avins wrote:> Richard Owlett wrote: > > ... > >> More seriously I have 'gut feel' that "signal conditioning" might be >> best done externally to a "one size fits all" speech recognition program. > > > While that's absolutely correct, the reasons for using separate > processors to accomplish those functions don't apply if you write all > your own code. COTS reduces software cost, often at the expense of added > hardware. > >> I read reports on comp.speech.users of the importance of choosing just >> the right mike and having an "ideal" acoustic environment. >> >> I do not doubt these assertions are true. >> *THEY _SHOULD NOT_ BE TRUE* !!!!!!!!!!!!!!!!!!!!!!!! > > > I agree about "just the right mic", but it must be true that quieter and > less reflective backgrounds are better. > >> Gee, why do people say I tilt at windmills ;? > > > You have to do a thing yourself if you want it done right. Some things > are not worth doing yourself. Tilting at windmills is wanting those > things to be right anyway. > > JerryTaking items in ~reverse order: Once had a boss who said I should never work for a profit oriented concern. I should work for someone like Bureau of Standards whose goal was tweaking the last decimal digit ;) I'll summarize discussion 1. placing a "black box" between microphone and a speech recognition system is not unheard of 2. it has prove feasible on occasion 3. whether or not it is reasonable is open to debate -- typical engineering trade off(s) of cost vs complexity vs 'figure of merit' I my case it is reasonable because it is feasible as I wish to test some ideas and could use a standard SR program behind my "black box". Now to "real" [aka "commercial"] world What would cost be in high hundreds to low thousands of units per year 1. monaural 44 kHz ADC 2. DSP based filter with a. 4-5 relatively broad passbands ( ie 1/formant ) b. 5-10 relatively sharp stopbands c. less than 1/4 sec latency What constraints have I not mentioned -- I've a few ideas but I'm looking for independent feedback I'm looking for something between a WAG and a SWAG.
Reply by ●November 9, 20052005-11-09
"Richard Owlett" <rowlett@atlascomm.net> wrote in message news:11n4mu2o064qp7e@corp.supernews.com...> Jerry Avins wrote: >> Richard Owlett wrote: >> >> ... >> >>> More seriously I have 'gut feel' that "signal conditioning" might be best >>> done externally to a "one size fits all" speech recognition program. >> >> >> While that's absolutely correct, the reasons for using separate processors to >> accomplish those functions don't apply if you write all your own code. COTS >> reduces software cost, often at the expense of added hardware. >> >>> I read reports on comp.speech.users of the importance of choosing just the >>> right mike and having an "ideal" acoustic environment. >>> >>> I do not doubt these assertions are true. >>> *THEY _SHOULD NOT_ BE TRUE* !!!!!!!!!!!!!!!!!!!!!!!! >> >> >> I agree about "just the right mic", but it must be true that quieter and less >> reflective backgrounds are better. >> >>> Gee, why do people say I tilt at windmills ;? >> >> >> You have to do a thing yourself if you want it done right. Some things are >> not worth doing yourself. Tilting at windmills is wanting those things to be >> right anyway. >> >> Jerry > > I'll summarize discussion > 1. placing a "black box" between microphone and a speech recognition system is > not unheard of > 2. it has prove feasible on occasion > 3. whether or not it is reasonable is open to debate -- typical engineering > trade off(s) of cost vs complexity vs 'figure of merit' > > I my case it is reasonable because it is feasible as I wish to test some ideas > and could use a standard SR program behind my "black box".Could the "black box" be rolled into the main CPU? That is kind of the crux of the HW vs. SW discussion.> Now to "real" [aka "commercial"] world > > What would cost be in high hundreds to low thousands of units per year > > 1. monaural 44 kHz ADC > 2. DSP based filter with > a. 4-5 relatively broad passbands ( ie 1/formant ) > b. 5-10 relatively sharp stopbands > c. less than 1/4 sec latency > > What constraints have I not mentioned -- I've a few ideas but I'm looking for > independent feedbackThe ADC wouldn't be more than a couple of bucks, and the DSP <$10. But you have to figure out how you interface to the PC (USB, PCI, etc.), power supply, circuit board size, etc. before you can accurately estimate cost. You probably want a mic pre-amp of some sort too, no? Maybe one of the guys who sells hardware can give better numbers.
Reply by ●November 9, 20052005-11-09
Jon Harris wrote:> "Richard Owlett" <rowlett@atlascomm.net> wrote in message > news:11n4mu2o064qp7e@corp.supernews.com... > >>Jerry Avins wrote: >> >>>Richard Owlett wrote: >>> >>> ... >>> >>> >>>>More seriously I have 'gut feel' that "signal conditioning" might be best >>>>done externally to a "one size fits all" speech recognition program. >>> >>> >>>While that's absolutely correct, the reasons for using separate processors to >>>accomplish those functions don't apply if you write all your own code. COTS >>>reduces software cost, often at the expense of added hardware. >>> >>> >>>>I read reports on comp.speech.users of the importance of choosing just the >>>>right mike and having an "ideal" acoustic environment. >>>> >>>>I do not doubt these assertions are true. >>>>*THEY _SHOULD NOT_ BE TRUE* !!!!!!!!!!!!!!!!!!!!!!!! >>> >>> >>>I agree about "just the right mic", but it must be true that quieter and less >>>reflective backgrounds are better. >>> >>> >>>>Gee, why do people say I tilt at windmills ;? >>> >>> >>>You have to do a thing yourself if you want it done right. Some things are >>>not worth doing yourself. Tilting at windmills is wanting those things to be >>>right anyway. >>> >>>Jerry >> >>I'll summarize discussion >>1. placing a "black box" between microphone and a speech recognition system is >>not unheard of >>2. it has prove feasible on occasion >>3. whether or not it is reasonable is open to debate -- typical engineering >>trade off(s) of cost vs complexity vs 'figure of merit' >> >>I my case it is reasonable because it is feasible as I wish to test some ideas >>and could use a standard SR program behind my "black box". > > > Could the "black box" be rolled into the main CPU? That is kind of the crux of > the HW vs. SW discussion. >Yes that is how it is done in typical system. But I'm specifying that it be external.> >>Now to "real" [aka "commercial"] world >> >>What would cost be in high hundreds to low thousands of units per year >> >>1. monaural 44 kHz ADC >>2. DSP based filter with >> a. 4-5 relatively broad passbands ( ie 1/formant ) >> b. 5-10 relatively sharp stopbands >> c. less than 1/4 sec latency >> >>What constraints have I not mentioned -- I've a few ideas but I'm looking for >>independent feedback > > > The ADC wouldn't be more than a couple of bucks, and the DSP <$10. But you have > to figure out how you interface to the PC (USB, PCI, etc.), power supply, > circuit board size, etc. before you can accurately estimate cost. You probably > want a mic pre-amp of some sort too, no? Maybe one of the guys who sells > hardware can give better numbers. > >
Reply by ●November 12, 20052005-11-12
Richard Owlett wrote:> Follow up set to comp.dsp as that is group I follow and am thinking in > those terms > > Bevan Weiss wrote: >> krg wrote: >> >>> Posted To: >>> comp.dsp, sci.electronics.misc, rec.music.makers.synth >>> >>> Hello people, >>> Getting straight on to the topic, I read a lot about cool >>> effects like flanging, reverb, and ... <you got the idea>, and also >>> that how you can create these with your own programs in C. I believe I >>> know enough C to carry things on my own, but I just need a start. >>> All I want to know is how to get those samples of that fav song >>> of mine that go out of my PC, so that I can really grab them and do >>> algebra that sounds good to me and finally play it. >>> Thanks for reading my post and further more if you actually >>> help. >>> >> >> Not quite the right newsgroup for that question, however... >> You'll either need a decoder for the particular file format that you're >> wanting to play around with, or you'll have to look into directly >> modifying the Direct-Sound (or equivalent) buffers to allow for the >> effects you desire. >> >> Once you've got the buffer containing your samples then it's just a >> matter of applying these samples to a filter to produce the effects you >> desire. The filter structure would be entirely up to you, however given >> that it's audio that you're dealing with an IIR filter would probably >> suffice for pretty much everything that you're wishing to do. >> >> Quite a few modern sound cards already have the capability to provide >> these effects on-board (i.e. without additional CPU load) so you'd just >> need to look into utilizing those features if this is more what you're >> trying to do. > > What cards would this be or can you suggest appropriate Google search > terms? > > What effects are possible on which cards? > > I'm mulling some wild ideas and need grist for the mill so to speak. > > Practicality is the *LEAST* of my concerns. > I am in "brain storming" mode ;} >If you really want to cut loose, look for boards with a TI TMS32C8X quad DSP. -- JosephKK
