Computer Audio Asylum

RE: Questions about programmatically controlling CPlay

194.179.55.200

ivigueras@terra.es

A

In Reply to: RE: Questions about programmatically controlling CPlay posted by cics on July 21, 2009 at 10:47:28

cics,

it would be good that all user interface's services (displaying and keyboard functions) were completely separated from the main engine of the application and to communicate them via a messaging API -as ussual in Unix aplications-.

This will facilitate us the development of new interfaces, without having to worry about the main engine.

Regards.
Ignacio.

Regards.
Ignacio.

Follow Ups:

RE: Questions about programmatically controlling CPlay - cics 10:47:52 07/27/09 (2)
Good idea. Skin is a separate component and a simpler version can be implemented as you described, i.e. a simple DSP message processor. This could be cPlay as a DLL version. Your thoughts?
- RE: Questions about programmatically controlling CPlay - ivigueras@terra.es 01:11:37 07/28/09 (1)
  I believe that cPlay must work as a service, getting his usual configuration paramaters from a configuration file and, while running, wait for messages from the user interfaces. A DLL must be a static component, not an active component.
  
  The first step would be to fix the functions of cPlay and the interfaces and to design the messages protocol between both.
  
  There are many ways for this messages exchange: you can use memory buffers, exchange registers, FIFO queues, etc, if you want to maintain the integrity of the design. But -and I know that you prefer not initiate the communications services-, I believe that best would be use a tradicional IP port. This standardizes the design and makes it independent of the architecture. In this case, for example, I could get a very simple PC exclusively dedicated and optimized to cMP/cPlay and the client interface in any other system: windows, linux, mac, etc, without consuming resources of cMP/cPlay. This, also, would facilitate the use of external storage and release cPlay the need to control it.
  
  Even better: what if we released cPlay of the tasks of the DSP and it is limited to handle the audio you are serving, decompressed and upsampled, from an external computer?. I am absolutely sure that the resources and power consumption of communications services are much lower than the DSP are. You yourself has admitted that cPlay sounds worse when must to decompress the FLAC files. Let alone deal cPlay control audio and outsource all other tasks.
  
  Now, I have got some time. I could help in the design development. Send me an email.
  
  Regards.
  Ignacio.
  Regards.
  Ignacio.
  - RE: Questions about programmatically controlling CPlay - cics 13:39:52 07/28/09 (0)
    Unfortunately some win32 apis must be used for best performance in cPlay (although this is limited and can be ported without too much effort). My preference is to limit interaction to just the kernel. I'll meditate on a possible solution, perhaps just a simple .lib that you can use...

Post a Followup:

FAQ

Post a Message!

Forgot Password?

Moniker (Username):
Password (Optional):
	Remember my Moniker & Password (What's this?) Eat Me
E-Mail (Optional):
Subject:

Message:	(Posts are subject to Content Rules)

Optional Link URL:
Optional Link Title:
Optional Image URL:
Upload Image:
E-mail Replies:	Automagically notify you when someone responds.

To view your new posting or follow-up, click on the RELOAD or REFRESH button on your browser.

This post is made possible by the generous support of people like you and our sponsors:

Signature Sound

[ Signature Sound Lounge ]