being serious about the NG of zinf

As is known, i'm working on a complete rewrite of zinf. Why, how would 
this still be zinf if it's a complete rewrite and the current zinf has 
no documented specs? Well, it would be zinf by not just looking like 
zinf but succeeding in the goals that zinf has wanted to succeed in. 
This would be internet streaming, audio data management, low system 
footprint, and extendability. I'm always looking for more people who 
want to help work on and give input on this while it's still feasible to 
change the framework of things.  I'm talking about programming input, 
ideas of what datatypes should be used for what and what ways to code 
for this or that.  That would be really helpful.

Right now I'm opposed to using threads for the main player.
Threads could possibly be used in the situation where we're streaming or 
playing from the internet. This is because of a couple reasons. We could 
have a large output buffer which may make reading from the stream be in 
longer intervals than ip allows for timeouts, thus losing our 
connection. Also, for streams, we may miss packets during our requests 
for more data.
The only other time we need to think about threads is when adding files. 
  But this is an easy one, and an example that illustrates the objective 
nature of the new player.
I'll explain.  After making our selection we update the playlist with 
all the new filenames (if we selected files) and leave other data 
elements blank. We then create a thread and then move on to whatever the 
player is doing.  In that thread (if we selected a directory or 
directories we scan them and create a vector of strings containing all 
the files with types we can use) we construct an addfile object that is 
sent a vector of strings which refer to the name of every file we want 
to add upon construction and a pointer to the playlist.  The playlist is 
just a map with the key being the filename and the value being a 

Re: being serious about the NG of zinf

Ed Sweetman writes:

> Right now I'm opposed to using threads for the main player.
> Threads could possibly be used in the situation where we're streaming or 
> playing from the internet. This is because of a couple reasons. We could 
> have a large output buffer which may make reading from the stream be in 
> longer intervals than ip allows for timeouts, thus losing our 
> connection. Also, for streams, we may miss packets during our requests 
> for more data.

With most desktop environment, X-Windows, or MS-Windows, sometimes certain 
operations will lock the entire display, and any process that requests any 
kind of a UI-related operation will be blocked.  The most common example 
would be resizing a desktop window.  The entire display will be locked so 
that the display manager can scribble over the entire display with the 
rubberband outline of the resizing window.

If your main application thread is multiplexing between pushing audio out, 
and updating the display, the audio playback is going to come to a 
screeching halt pretty quickly.  Not nice.

From a purely theoretical design, I think that audio playback needs a 
minimum of two threads.

The first thread's only job would be to push audio out.  No other I/O.  No 
dynamic memory allocation from the heap.  It's going to be reading from a 
reasonably sized memory buffer that the second thread will be filling, and 
writing the data out to the audio device.  Where possible, it's going to 
be set to run as a high priority process.  No other syscalls or I/O 
interaction except for audio out.  You want to minimize any possibility of 

Re: Re: being serious about the NG of zinf

Sam Varshavchik wrote:
> Ed Sweetman writes:
> 
>> Right now I'm opposed to using threads for the main player.
>> Threads could possibly be used in the situation where we're streaming 
>> or playing from the internet. This is because of a couple reasons. We 
>> could have a large output buffer which may make reading from the 
>> stream be in longer intervals than ip allows for timeouts, thus losing 
>> our connection. Also, for streams, we may miss packets during our 
>> requests for more data.
> 
> 
> With most desktop environment, X-Windows, or MS-Windows, sometimes 
> certain operations will lock the entire display, and any process that 
> requests any kind of a UI-related operation will be blocked.  The most 
> common example would be resizing a desktop window.  The entire display 
> will be locked so that the display manager can scribble over the entire 
> display with the rubberband outline of the resizing window.
> 
> If your main application thread is multiplexing between pushing audio 
> out, and updating the display, the audio playback is going to come to a 
> screeching halt pretty quickly.  Not nice.

the gui can sit on a thread by itself via gdk_thread

>> From a purely theoretical design, I think that audio playback needs a 
> 
> minimum of two threads.
> 
> The first thread's only job would be to push audio out.  No other I/O.  

Re: being serious about the NG of zinf

Ed Sweetman writes:

> the time and how to handle filling the buffer at the same time.  What we 
> could do time the player on a loop that is run in the output plugin that 
> queries the audio buffer waiting for a 2byte decrease from the max with 
> initial time's starting at position given by the UI. That should be 
> sufficient.

I'm not sure Linux's /dev/dsp has this kind of granularity.  As I recall, 
you get to choose audio block sizes as an even power of two, I forget the 
minimum.  And you specify the number of audio blocks the driver will 
allocate, and dsp will only tell you when it played each block.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: being serious about the NG of zinf

Sam Varshavchik wrote:
> Ed Sweetman writes:
> 
>> the time and how to handle filling the buffer at the same time.  What 
>> we could do time the player on a loop that is run in the output plugin 
>> that queries the audio buffer waiting for a 2byte decrease from the 
>> max with initial time's starting at position given by the UI. That 
>> should be sufficient.
> 
> 
> I'm not sure Linux's /dev/dsp has this kind of granularity.  As I 
> recall, you get to choose audio block sizes as an even power of two, I 
> forget the minimum.  And you specify the number of audio blocks the 
> driver will allocate, and dsp will only tell you when it played each block.
> 

/dev/dsp referring to OSS i assume, i'm referring to requesting the 
current buffer size as opposed to the allocated buffer size.  The 
difference being 2bytes when we then go and repeat our read cycle and 
thus update the time and position. I'm not saying to allocate 2 bytes 
only. We should be able to ask how much data is in the buffer and 
compare to the allocated, cant we?  I haven't worked with oss much at 
all, been using alsa since before 2.3 got going.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: being serious about the NG of zinf

On Wed, Apr 30, 2003 at 09:01:24PM -0400, Ed Sweetman wrote:
> Right now I'm opposed to using threads for the main player.

That's a good start.  There's rarely a problem that can be solved with
threads that can't be solved more simply and reliably with other
means.

While the pipeline probably doesn't need to be threaded, we might want
to allow the UI to exist on another thread, and then put all the
UI/pipeline interactions in a very tight interface.

> In other areas of design, ideas such as the mapped strings for managing 
> preferences are going to be put into use.  [...]

Great.  I was thinking about something very similar.  The preferences
coupling should be as loose as possible.

> changing in the meantime, we need a boolean member to info called lock. 

Checking a variable doesn't prevent race conditions at all because
threads can be switched after checking the condition, but before
reading the data.

We'll either need to use a real synchronization object, or else
stipulate that plugins can only read the info object from the main
(creation) thread.

> I do 
> still have my doubts on how feasible it will be to not depend on libs 
> for certain protocols in the input plugins so this is still

Re: being serious about the NG of zinf

Tim Lesher wrote:
> On Wed, Apr 30, 2003 at 09:01:24PM -0400, Ed Sweetman wrote:
> 
>>Right now I'm opposed to using threads for the main player.
> 
> 
> That's a good start.  There's rarely a problem that can be solved with
> threads that can't be solved more simply and reliably with other
> means.
> 
> While the pipeline probably doesn't need to be threaded, we might want
> to allow the UI to exist on another thread, and then put all the
> UI/pipeline interactions in a very tight interface.
> 
> 
>>In other areas of design, ideas such as the mapped strings for managing 
>>preferences are going to be put into use.  [...]
> 
> 
> Great.  I was thinking about something very similar.  The preferences
> coupling should be as loose as possible.

preferences and the playlist are just mapped strings.  plain and simple. 
  Of course like the preferences, the player isn't going to talk to the 
mapped string directly.  The preferences are wrapped in the info class 
and accessed by methods in it.  The playlist will be accessed by a 
playlist class that gives complete functionality that you've come to 
expect from the gtk ui and more.  I'd like to offload functionality from 
the UI's and allow the ui subsystem to be just that, the user interface 
and not part of the "program."

[C. Scott Ananian] Bug#167527: zinf: Bad URL parsing.

I just got this bugreport, maybe someone can look into it - seems easy
to fix...

From: C. Scott Ananian <cananian <at> lm.lcs.mit.edu>
Subject: Bug#167527: zinf: Bad URL parsing.
Date: 2003-05-07 23:20:49 GMT

*** Please type your report below this line ***
The URL parsing is done in httpinput.cpp with the following line: 
   iRet = sscanf(m_path, " http: //%[^:/]:%d", szHostName, &iPort);
Bcc: "C. Scott Ananian" <cananian <at> lm.lcs.mit.edu>
X-Mailer: reportbug 2.10.1
Date: Wed, 07 May 2003 19:20:48 -0400

Package: zinf
Version: 2.2.2+cvs20030131+dp1-4
Followup-For: Bug #167527

This code is obviously broken in that it *requires* the *optional* port field
in the URL.  I didn't obviously see where the extra colon in the original
reporter's problem URL would get misparsed, but the URL handling is
sloppy at best.  It should be rewritten to conform with the RFCs.
 --scott

Re: [C. Scott Ananian] Bug#167527: zinf: Bad URL parsing.

I've rewrote the code last night.. I'll put into CVS after a bit of
testing.   This should also close bug #192360 and might fix #192361

Also I think #164111,#161977 has been taken care of ( cooperative volume
off by default).

#160710 looks to be URL parsing bug .. it may be fixed with the new
code.

#160884 is in code that is no longer used.. plm/metadata/id3v1

#164515 should no longer be valid.. but I will check.

#164517 is unreproducible

#181780 is unpreproducible.. In fact, my main platform is a dual head
xinerama setup.

#185815 has a fix in CVS, but has not been tested.

#188072 needs more information .. what copyright file?

#85066 is no longer vaild

#125395 I believe this is fixed with the recent updates 

#100458 has been fixed

On Thu, 2003-05-08 at 01:03, Andreas Rottmann wrote:

Re: [C. Scott Ananian] Bug#167527: zinf: Bad URL parsing.

This is fixed in CVS.

While doing the fix, I noticed that we seem to have several
implementations of http stuff in zinf (see io/http/httpinput.cpp,
lib/http/src/Http.cpp)   Since this code is remarkable similar,
yet has different capabilities (one supports ipv6), httpinput
supports icecast extras.   

Does anybody know of a good c++ library for http handling? 
I would like to consolidate the two implementations (they both
could use some cleaning up).

On Thu, 2003-05-08 at 01:03, Andreas Rottmann wrote:
> I just got this bugreport, maybe someone can look into it - seems easy
> to fix...
> 
> 
> ______________________________________________________________________
> 
> From: C. Scott Ananian <cananian <at> lm.lcs.mit.edu>
> To: Debian Bug Tracking System <167527 <at> bugs.debian.org>
> Subject: Bug#167527: zinf: Bad URL parsing.
> Date: 07 May 2003 19:20:49 -0400
> 
> X-From-Line: debbugs <at> master.debian.org Thu May 08 09:45:23 2003
> Return-path: <debbugs <at> master.debian.org>
> Envelope-to: andy <at> localhost
> Delivery-date: Thu, 08 May 2003 09:45:23 +0200
> Received: from localhost ([127.0.0.1] ident=andy)
> 	by alice.rhinosaur.lan with esmtp (Exim 3.36 #1 (Debian))