and how does that work? The CPU does not know that instructions are intended to produce sounds, only the operating system knows that. Also, PearPC is not just interpreting instructions from x86 to PPC, it is also handling the way that Darwin addresses the hardware, so unless sound has been implemented, it doesn't matter what OSX instructions are sent to the processor, PearPC does not have any code to interpret sound that originates from OSX.
I really wish one of the developers would step in and settle this. Does anyone know how to contact one of them?
all is quite simple but atm will not work due the slowlyness of network.. and the cpu emulation is slow too
causing a crash or a huge lag
This is a point I made earlier, but it was ignored then.
Once you've made something idiot proof, they go and invent a better idiot!
Colinux is an entirely different animal to PearPC, as it is not an emulator.
I don't really know how I can explain this any better, but completely forget what happens with TCP/IP and a remote device - I have no disagreement whatsoever that the mechanics of sending the sound in packets and playing it through a remote device will work. I also have no problems with understanding how you intend to use a loopback adapter.
The problem is, that PearPC sits between OSX and ALL of it's interactions with hardware. This means that the operating system, drivers and applications all have to interact with PearPC. If a particular aspect of that communication is not implemented, then you cannot use it.
Why do you think the hardware CD could not be accessed until PPC was patched? It wouldn't matter if you used loopback devices, virtual drivers, etc. - the only way it was ever going to work was when PPC was patched. The same is true for sound.
If you are going to post all these post suggesting that something can be done, then go ahead and do it.
Don't talk the talk if you can't walk the walk.
Once you've made something idiot proof, they go and invent a better idiot!
i am searching for a virtual sound driver for osx, but i can't find one.
if anyone knows about one, please tell me and i'll try. (i would like to hear about a streaimg server for osx too)
If your network is working, you can always set PearPC's iTunes to share it's songs, then access them with iTunes on the host computer. Not that there's any use for that. At all.
well in vpc the complete computer system is emulated, all the hardware and everything, so if win does a call to output a sound it goes through the emulated sound card that is written to work inside macos and behave like the pc sound card.
now to send sound the way pc-digger suggests is to forget about the card emulation and stream the sound over the nic to the win side.
this would work for some things, but it would be very hard to sync sounds to events. eg hearing a key click when typing, it would lag.
now even if you sent it to another computer the sound would still lag.
this i know from live chat with the computer beside me. always a delay and not running emulation.
so I suppose that the idea is good but I don't see it as practical.
to be able to emulate a sound device within macos would be a much better thing to do. at least it would sync better as it would send the sound out at the correct time and not have to wait (networking always waits)
I'm with Yukon Kid. The network thing would be a temporary hack. A dedicated soundcard emulation is needed earlier or later to be on the safe side.
BTW, someone seems to work on a Mac onboard sound emulation. This is what I found on the devel list, posted by canadacow:
I"ve been working on the sound emulation thus far and its been an uphill
battle finding good documentation. First, I"ve decided to emulate the
Burgandy onboard sound hardware. I did this because there is support in the
PPC Linux kernel for it and in OS 9 and OS X. I decided against MOL because
it requires their special driver which may or may not be supported in a
later version of OS X (and would have to be rewritten). With the onboard
emulation, we"d simply keep the DBDMA as implemented and move on with a more
recent onboard Codec.
I chose not to emulate the Sound Blaster or AC97 because I was unable to
find any specific details on how this is accomplised in a real Mac. If
anyone would like to fill me in on how this is done I may change gears.
The current status is that I have all the Mutex and Channel registers
working on the hardware, as well as the firmware registration. Thus, the
sound shows up under system preferenes and I can adjust the volume. PearPC
crashes any time a sound is played however, either because I haven"t figured
out the IRQs yet, or because its trying to use "stfiwx" instruction to
calculte dB gains and it appears this instruction is stubbed at the moment.
If anyone has any suggestions or ideas, please feel free to comment.
I think the onboard sound emulation is the right way. Keep it as simple as possible for now. Also, most PPC OSes come with drivers for it.
kybernaut wrote:I'm with Yukon Kid. The network thing would be a temporary hack. A dedicated soundcard emulation is needed earlier or later to be on the safe side.
BTW, someone seems to work on a Mac onboard sound emulation. This is what I found on the devel list, posted by canadacow:
I"ve been working on the sound emulation thus far and its been an uphill
battle finding good documentation. First, I"ve decided to emulate the
Burgandy onboard sound hardware. I did this because there is support in the
PPC Linux kernel for it and in OS 9 and OS X. I decided against MOL because
it requires their special driver which may or may not be supported in a
later version of OS X (and would have to be rewritten). With the onboard
emulation, we"d simply keep the DBDMA as implemented and move on with a more
recent onboard Codec.
I chose not to emulate the Sound Blaster or AC97 because I was unable to
find any specific details on how this is accomplised in a real Mac. If
anyone would like to fill me in on how this is done I may change gears.
The current status is that I have all the Mutex and Channel registers
working on the hardware, as well as the firmware registration. Thus, the
sound shows up under system preferenes and I can adjust the volume. PearPC
crashes any time a sound is played however, either because I haven"t figured
out the IRQs yet, or because its trying to use "stfiwx" instruction to
calculte dB gains and it appears this instruction is stubbed at the moment.
If anyone has any suggestions or ideas, please feel free to comment.
I think the onboard sound emulation is the right way. Keep it as simple as possible for now. Also, most PPC OSes come with drivers for it.
--kybernaut
you're right there kybernaut, should be along any time soon now =)
PPC_Digger wrote:i am searching for a virtual sound driver for osx, but i can't find one.
if anyone knows about one, please tell me and i'll try. (i would like to hear about a streaimg server for osx too)
PPC_Digger wrote:i am searching for a virtual sound driver for osx, but i can't find one.
if anyone knows about one, please tell me and i'll try. (i would like to hear about a streaimg server for osx too)
The current status is that I have all the Mutex and Channel registers
working on the hardware, as well as the firmware registration. Thus, the
sound shows up under system preferenes and I can adjust the volume. PearPC
crashes any time a sound is played however, either because I haven"t figured
out the IRQs yet, or because its trying to use "stfiwx" instruction to
calculte dB gains and it appears this instruction is stubbed at the moment.
He says here that may be the problem is with the "stfiwx" instruction, so this is from the 0.4pre changelog:
version 0.4pre (not yet released):
- CPU: stfiwx implemented
